189 8069 5689
在互联网中大型项目中，读写分离应该是我们小伙伴经常听说的，这个主要解决大流量请求时，提高系统的吞吐量。因为绝大部分互联网产品都是读多写少，大部分都是读请求，很小部分是写请求。
创新互联公司专业为企业提供丰宁网站建设、丰宁做网站、丰宁网站设计、丰宁网站制作等企业网站建设、网页设计与制作、丰宁企业网站模板建站服务，十多年丰宁做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
上图：
1.一个主库负责写请求，更新数据
2.两个从库负责读请求，可以提高系统吞吐量
3.主库和从库之间同步数据
上图中业务流程
1.写请求A进行数据更新，但写库还没有来得及把更新的数据更新到读库
2.读请求B进行数据查询，请求B是访问的读库，获取的是旧值
3.因为写库和读库之间存在同步延迟，导致数据在不同库中不一致
这个问题我们如何解决？
我们一般用的数据库是MySQL和oracle，mysql是我们互联网项目都会用到的，oracle一般大公司用的比较多（很贵啊）。
我们分析一下问题，原因就是在主库（写库）与从库（读库）之间数据同步延迟导致，mysql中有全同步复制机制、半同步复制、异步复制三种复制方案（小伙伴可以自行去了解）。
mysql全同步复制
全同步复制，当A提交更新请求主库事务之后，不是立即返回，而是等到所有的从库节点必须收到、APPLY并且提交这些事务，主库线程才返回请求A结果，才能做后续操作。这样就解决了数据同步延迟的问题。
问题：但这个同步方案严重的问题就是写请求耗时会很长，而且会随者从库数量增加，耗时也会增加。（不推荐）
oracle共享存储
上图采用了oracle RAC方案，DB服务其实就代表一个应用服务，所有的数据存储在同一个地方，所有就不存在数据同步这个问题。当然这个部署方案不是我们严格意义上面的读写分离，存储是独立的。
问题：oracle成本很高，对存储硬件要求很高。
我们设计任何架构方案，都要围绕着业务，如果业务能够接受可以不解决；其实很多互联网产品都有短时间的数据不一致问题。如：58同城，美团，贴吧等。
但有些场景是不允许的。如：
上图中：
1.用户写了一篇文章，点击保存按钮
2.系统执行保存方法，提示用户保存成功
3.保存成功后一般系统就会立即跳转到文章列表，按照时间倒序，最新的文章排在第一个，这个业务是很正常的，让用户可以看到自己的文章列表（我们的头条号就是这样的）
4.这样就是调用获取文章列表的方法getArticleList，但这个方法是读请求，走的是从库。
5.如果出现主库和从库同步延迟，就出现了不一致。
这样用户就看不到他刚刚提交保存的文章，这个用户是接受不了的。那我们怎么解决？
这个方案是从一个朋友公司用到的，老顾没有采用过。一些业务的操作是有前端页面的，不管是网页或App等。此方案的思路就是把之前保存的文章缓存到客户端，在用户到文章列表时，数据的组成就是（客户端缓存文章 + 后端读库返回的文章数据）。客户端要做的就是缓存要设置一个时间（这个缓存时间，可以预估主库同步到从库的时间延迟）；以及要做文章去重，防止读库已经同步完成，客户端缓存没有过期。
问题：客户端逻辑复杂；客户端有缓存数据大小的限制，不能保存大数据。列表分页处理复杂。
上图流程：
1.A发起写请求，更新了主库，但在缓存中设置一个标记，代表此数据已经更新，标记格式（业务代号：数据库：表：主键ID）根据自己业务场景。
2.设置此标记，要加上过期时间，可以为预估的主库和从库同步延迟的时间.
3.B发起读请求的时候，先判断此请求的业务在缓存中有没有更新标记
4.如果存在标记，走主库；如果没有走从库。
这个方案就有效了解决了数据不一致的问题。
但这个方案会有个严重的问题，也就是每次的读请求都要到缓存中去判断是否存在缓存标记，如果是单机部署用的是jvm缓存，对性能还好；但如果是集群部署缓存肯定用redis，每次读都要和redis进行交互，这样肯定会影响系统吞吐量。
那怎么办？怎么办？继续往下看
上图流程：
1.用户A发起写请求，更新了主库，并在客户端设置标记，过期时间，如：cookies
2.用户A再发起读请求时，带上这个本地标记在后端
3.后端在处理请求时，获取请求传过来的数据，看有没有这个标记（如：cookies）
4.有这个业务标记，走主库；没有走从库。
这个方案就保证了用户A的读请求肯定是数据一致的，而且没有性能问题，因为标记是本地客户端传过去的。
但有写小伙伴就会问那其他用户在本地客户端是没有这个标记的，他们走的就是从库了。那其他用户不就看不到这个数据了吗？说的对，其他用户是看不到，但看不到的时间很短，过个1～10秒就能够看到。
但这个方案解决了当前用户的数据一致性的问题，如上面举的例子，写文章，然后到文章列表，本用户是能够看到的。其他用户暂时看不到是没有关系的。还是那句话，脱离业务的方案是耍流氓。（推荐）
总结：大家应该按照自己不同的业务场景，选择不同的方案；方案各有千秋，具体看业务场景
