2：为什么要读写分离

1：为什么数据库要读写分离

在互联网的系统应用是一个  读多写少的应用，比如电商系统中，商品浏览的次数是比下单要多的。数据库承载压力大，主要是由这些读的请求造成的，那么我们是不是可以把读操作和写操作分开，让所有读的请求落到专门负责读的数据库上，所有写的操作落到专门负责写的数据库上，写库的数据同步到读库上，这样保证所有的数据修改都可以在读取时，从读库获得，系统的架构如图所示：

 如果系统的读请求比较多的话，读库可以多部署几台，这样读请求就可以均摊到多台读库上，降低每一个读库上的压力。但是在写数据的时候，数据要落在一个确定，且唯一的写库中。上图中，咱们的写库只有一个，你当然可以部署多个写库，但是数据怎么分片是一个十分重要的问题，目前仅以一个写库为例，比如：商户发布商品时，将这个商品的数据落在了写库上，同时，写库将这条数据同步给两个读库，买家在网站浏览商品时，会从读库将这个商品数据读取，至于从哪个读库取出数据，那就要看这个请求在当前的路由情况了。

2：读写分离的优缺点

优点：

• 将大量的读操作从数据库中剥离，让读操作从专用的读数据库中读取数据，大大缓解了数据库的访问压力，也使得数据的响应速度得到了大大的提升。

缺点：

• 数据从写入到数据库，到从数据库取出，读写分离的架构多了一个同步的操作，同步的操作时间是多少，延迟如果太大对系统有没有影响，如果同步挂了怎么办？例如：电商个人中心的订单列表页，功能挺简单的，只需要将订单数据取出来，在页面上展示就可以了，但是在做的时候，订单以及订单相关的数据都是从读库取出的，其中就包括支付状态，这个用户非常敏感的字段。就在某一天的某一时段，突然接到了用户大量的投诉，说用户已经付了钱了，但是订单的状态还是未支付，去数据库里查询，发现订单状态就是未支付，没有问题。为了保险起见，去写库再查一下这个订单吧，发现写库的订单状态确实是已支付，这下完了，写库和读库取出来的数据不一致，问题根源就是    同步挂掉了
• 当同步挂掉，或者同步延迟比较大时，写库和读库的数据不一致，这个数据的不一致，用户能不能接受，订单支付状态这个不一致当然是不能接受的了，其他的业务场景能不能接受呢？这个要对不同的业务场景做具体的分析了

3：读写分离的适用场景

一些对数据实时性要求不高的业务场景，可以考虑使用读写分离。但是对数据实时性要求比较高的场景，比如订单支付状态，还是不建议采用读写分离的，或者你在写程序时，老老实实的从写库去读取数据，如果你做数据的同步，你的网络延迟应该在5ms以内，这个对网络环境要求是非常高的，大家可以ping 一下你网络中的其他机器，看看能不能达到这个标准，如果你的网络环境很好，达到了要求，那么使用读写分离是没有问题的，数据几乎是实时同步到读库，根本感觉不到延迟。

读写分离呢，大家在使用的时候，还是要从业务出发，看看你的业务是否适合使用读写分离，每种技术架构都有自己的优缺点，没有好不好，只有适不适合，只有适合业务的架构才是好的架构