Architect_006：数据库读写分离架构（摘录+整理）

数据库读写分离的设想源自于数据库双机热备功能。所谓双机热备，就是第一台数据库服务器，是对外提供增删改查业务的生产服务器；第二台数据库服务器，仅仅接收来自第一台服务器的备份数据。

可以想象，在实际运行中，第一台数据库服务器的压力，远远大于第二台数据库服务器。因此，很多人希望合理利用第二台数据库服务器的空闲资源。因此读写分离的想法就很自然的产生了。

读写分离的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。

当主数据库做了“增删改”操作之后，会立即将这个操作，同步到从数据库上。这是一个单向的同步。之所以选择单向同步，是因为如果是双向同步，那逻辑就非常复杂，而且还会大大降低性能。

关于数据同步，不同的数据库厂商有不同的解决方案。

1. MySQL数据库读写分离架构：Master-Slave 架构

除了数据库要做到主从数据库读写分离与数据同步之外，数据访问层（Data Access Layer）在设计上要做到：

（1）读写分离逻辑分批

（2）负载均衡

（3）失效转移（failover）

（4）数据库分区透明支持

在实现方式上，有两大实现模式：

（1）独立Proxy服务器

MySQL：mysqlproxy,Amoeba

PostgreSQL：PL/Proxy (Skype)

（2）通过DAL API
Java：Hibernate Shard，Ibatis Shard，HiveDB，Guzz
Python：Pyshards

2. Oracle数据库读写分离架构

主库负责写数据和读数据。读库只负责读数据。每次有写库操作，同步更新cache，每次读取先读cache在读DB。写库就一个，读库可以有多个，采用DataGuard或GoldenGate来负责主库和多个读库的数据同步。

那么数据库读写分离架构针对的是哪些数据呢？当然是读大于写并且数据量增加不是很明显的数据库，推荐采用“读写分离+缓存”的模式。

比如用户信息就属于此类数据。
用户注册、修改用户信息、记录用户登录时间、记录用户登录IP、修改登录密码，这些是写操作。但是这些操作次数都是很小的，所以整个数据库的写压力是很小的。
唯一一个比较大的就是记录用户登录时间、记录用户登录IP这类信息，只要把这些经常变动的信息排除在外，那么写操作可以忽略不计。所以读写分离首要解决的就是经常变化的数据的拆分，比如：用户登录时间、记录用户登录IP。这类信息可以单独独立出来，记录在持久化类的缓存中，因为这类信息的可靠性要求并不高。

参考文献：

1. http://blog.csdn.net/kobejayandy/article/details/8775255

2. http://tech.it168.com/a2011/0301/1161/000001161632.shtml

3. http://baike.baidu.com/link?url=6JrArrYGtgRXhOf7ndAY3vPFChS7Ea0qI98z62y5gqXKZIpms6b_uh7aN8df-K_XS0ROuPVspj82ok6zQcsP2q