这个也是面试中经常会聊到的一个话题，一般聊到数据库，都会问下数据库是怎么架构的，做了高可用没，还是读写分离的，下面就这个读写分离稍微简单记录下。
为什么要做读写分离
首先简单介绍下什么是读写分离，读写分离，就是让主数据库处理事务性增、改、删操作，而从数据库处理查询操作。然后主数据库变更的数据同步到从数据库。数据库的写操作是比较耗时的，如果大量的写操作是会影响到读到效率，根据二八法则，80%的数据库操作是读操作，剩下的20%则为写操作，读写分离后，可以大大提升单库无法支撑的负载压力。所以读写分离，解决的是，数据库的写入，影响了查询的效率。
什么业务适合做读写分离
MySQL的主从同步机制非常方便的解决了高并发读的应用需求，但这种方式有个比较大的缺陷在于MySQL的同步机制是依赖Slave(从库)主动向Master(主库)发请求来获取数据的(不管是拉还是推的方式)，Master与Slave 之间的数据同步延迟是完全没有保证的，短在1秒内，长则几秒、几十秒的都可能。所以在这种情况下，如果读到的数据业务场景对数据库实时性要求不高，那完全是没有问题，有哪些业务场景适合呢？比如常见的做门户网站，博客，论坛等等，这些数据晚点读出来影响是不大的。但是有些业务场景比如金融类的就不太适合，账户里面的可用资金要是没有同步过来的话，是有问题的。
怎么做读写分离
MySQL做读写分离方式很多，以前用过的有这些，amoeba,mysql-proxy,mycat等，自己可以选择自己合适的。
主从同步有时延问题
前面说过，首先要评估自己的业务场景适合不适合做读写分离，是否能容忍主从延时导致的数据不一致。另外确实用到读写分离，但是又要求数据不能有延迟，一般也有以下这些方案：
1.选择性读主。
特殊业务场景可以使用读和写都落到主库上，比如账号的可用资金做业务，像这种情况去读账号就不需要去从库里面读了，也去主库读即可。
2.缓存。
可以将对数据实时性较高的业务在主库操作完数据后放到一个分布式缓存里面，去读的话先从这个缓存里面去读。
其实现在的微服务架构里面很少有数据库读写分离一说，读写分离更多的业务场景还是在传统的单体应用架构和单数据库模式里面，微服务架构一般分库，分的很细，数据库做高可用，然后中间采用缓存来提升系统读性能。
