读写分库架构
我们一般应用对数据库而言都是“读多写少”，也就说对数据库读取数据的压力比较大，有一个思路就是说采用数据库集群的方案： 其中一个是主库，负责写入数据，我们称之为：写库； 其它都是从库，负责读取数据，我们称之为： 读库；
那么，对我们的要求是：
1. 读库和写库的数据一致；
2. 写数据必须写到写库；
3. 读数据必须到读库；
架构
从该系统架构中，可以看出：
- 数据库从之前的单节点变为多节点提供服务
- 主节点数据，同步到从节点数据
- 应用程序需要连接到2个数据库节点，并且在程序内部实现判断读写操作
这种架构存在2个问题：
1、应用程序需要连接到多个节点，对应用程序而言开发变得复杂
- 这个问题，可以通过中间件解决MyCat
- 如果在程序内部实现，可使用Spring的AOP功能实现（要求方法名要有一定的格式）
2、主从之间的同步，是异步完成，也就意味着这是 弱一致性
- 可能会导致，数据写入主库后，应用程序读取从库获取不到数据，或者可能会丢失数据，对于数据安全性要求比较高的应用是不合适的。
- 该问题可以通过PXC集群解决
中间件
通过上面的架构，可以看出，应用程序会连接到多个节点，使得应用程序的复杂度会提升，可以通过中间件方式解 决，如下：
从架构中，可以看出：
- 应用程序只需要连接到中间件即可，无需连接多个数据库节点
- 应用程序无需区分读写操作，对中间件直接进行读写操作即可
- 在中间件中进行区分读写操作，读发送到从节点，写发送到主节点
该架构也存在问题，中间件的性能成为了系统的瓶颈，那么架构可以改造成这样
这样的话，中间件的可靠性得到了保证，但是也带来了新的问题，应用系统依然是需要连接到 2 个中间件，又为应用
系统带来了复杂度。
