数据库的读写分离方案很多，这里介绍基于mysql数据库的读写分离方案。
比较常见的读写分离方案如下:
1 基于查询分离
最简单的分离方法是将读和写分发到主和从服务器上，这种策略很容易实现，但是仅限于一些能够容忍查询脏数据的操作。
举个例子来说,用户写入了一条评论，发往主库保存，查询的时候则是从从库拉取数据，由于主从数据库存在复制延迟，
用户很可能看不到自己的最新评论，这就是脏数据。
2 基于脏数据分离
这种策略并不关心从库是不是100%跟上了主库,这种策略让应用检查复制延迟,以确定从库是否太旧。
3 基于会话分离
另一个决定能否从从库读取数据的稍微复杂一点的方法是判断用户自己是否修改了数据。用户不需要看到其他用户的最新
数据，但需要看到自己的更新。可以再会话层设置一个标记位，表明做了更新，就将该用户的查询在一段时间内
总是指向主库。这是推荐的一种做法，因为他是在简单和有效性之间的一种很好的妥协。
我们还可以把基于会话的分离方法和复制延迟监控结合起来，如果用户在10秒前更新了数据,而所有备库延迟在5秒内，
就可以安全的从备库中读取数据，但为整个会话选择同一个备库是很好的主意,否则用户可能会奇怪有些备库的数据比较慢。
4 基于版本分离
这种策略与基于会话的分离方法相似,你可以跟踪对象的版本号或者时间戳,通过从备库读取对象的版本或时间戳来判断数据是否足够新。
如果备库的数据太旧，可以从主库获取最新的数据。
5 基于全局版本/会话分离
这个办法是基于版本分离和会话分离的变种.当应用执行写操作时，在提交事务后，执行一次show master status操作。然后在缓存中存储主库日志坐标，
作为被修改对象以及/或者会话的版本号。的那个应用连接到备库时，执行show slave status 并将备库上的坐标和缓存中的版本号对比，如果备库相比记录点更新，则
可以安全的读取备库数据。
