- 业务上的层级拆分：关联查询如何进行跨库的查询？
- 主从复制，数据不一致问题
- 第三方插件，半同步
- 一主一从，并不能提高程序的性能，但是能容灾，mater 挂了，slave 顶上。不需要考虑数据一致性问题，因为 slave 只是用来做备份的
作者：Gary Chen
读写分离指的是，通过增加一些节点，扩展读的能力。这些节点可以是主节点的全部内容的副本或者部分内容的副本，也可以是缓存产品。读写分离一般配合负载均衡产品使用。
对于读多写少（非更新查询为主）的负载，特别适合做读写分离。你需要留意的是，保证用户感知到自己所做的变更生效即可，用户很多情况下并不需要知道其他用户的改变。如果用户对于数据的一致性要求在某个时刻高，那么这部分数据，建议不要使用读写分离，MySQL的复制可能出现延时，无法满足业务需要。你可以采取变通的方式，比如，在用户修改了内容后，临时强制用户访问主节点，以获取一致性的数据，在过一段时间后，再让用户访问副本的数据，一般在此时，副本的数据已经同步到最新状态了。
读写分离往往和负载均衡技术配合使用。负载均衡软硬件产品有F5、Haproxy以及一些自己设计的MySQL Proxy代理等，负载均衡可以更高效的利用硬件，你可以设置权重，分配更多的流量给性能更好的机器，负载均衡产品一般还有故障检测、自动冗余切换功能，这可以大大提高你的可用性。
读写分离技术的一个难点在于延时的影响，你需要有一个手段确保你没有读取到太旧的数据，写操作和一些不能容忍延时的查询，需要指向主库。对于数据延时敏感度不高的数据，你需要定义延时的阈值，通过自动或者手工的方式处理延时数据对于用户体体验的影响。
你可以通过监控SHOW SLAVE STATUS里的输出Seconds_behind_master的方式判断是否有延时，但这种方式不太可靠。监控复制滞后（replication lag）的更稳健的方式是通过心跳表的方式。
我们很难确保MySQL的延时，因为网络波动、复制异常、性能问题都可能导致复制中断，而往往需要人工来进行干预，毕竟有能力开发专用的Proxy代理的公司很少，所以，不建议使用读写分离，采用读写分离是基于一个前提，主库已经出现读瓶颈，如果出现读瓶颈，使用缓存一般是更有效、更成熟的解决方案。
由于没有好的读写分离的方案，如果你一定要使用读写分离，推荐应用程序自身实现读写分离，把读的流量指向负载均衡产品或者Proxy代理。
读写分离，又往往和拆分数据有关联。部分数据更适合读写分离，部分数据更适合拆分。对于一致性要求很高的数据，往往很难以去拆分，使用读写分离保证适当的用户体验更可取。 如果一定要拆分，很可能导致架构、运维异常复杂。 在做数据架构的时候，要清楚数据的用户，细分各种数据，针对各种数据，进行各种处理，确保异常情况下的可用、可恢复，而不是简单的考虑 读写分离、水平扩展、垂直扩展这些更简单的分解。