关键词：
本文主要讨论这么几个问题：
（1）数据库主从延时为何会导致缓存数据不一致
（2）优化思路与方案
一、需求缘起
上一篇《缓存架构设计细节二三事》中有一个小优化点，在只有主库时，通过“串行化”的思路可以解决缓存与数据库中数据不一致。引发大家热烈讨论的点是“在主从同步，读写分离的数据库架构下，有可能出现脏数据入缓存的情况，此时串行化方案不再适用了”，这就是本文要讨论的主题。
二、为什么数据会不一致
为什么会读到脏数据，有这么几种情况：
（1）单库情况下，服务层的并发读写，缓存与数据库的操作交叉进行
虽然只有一个DB，在上述诡异异常时序下，也可能脏数据入缓存：
1）请求A发起一个写操作，第一步淘汰了cache，然后这个请求因为各种原因在服务层卡住了（进行大量的业务逻辑计算，例如计算了1秒钟），如上图步骤1
2）请求B发起一个读操作，读cache，cache miss，如上图步骤2
3）请求B继续读DB，读出来一个脏数据，然后脏数据入cache，如上图步骤3
4）请求A卡了很久后终于写数据库了，写入了最新的数据，如上图步骤4
这种情况虽然少见，但理论上是存在的， 后发起的请求B在先发起的请求A中间完成了。
（2）主从同步，读写分离的情况下，读从库读到旧数据
在数据库架构做了一主多从，读写分离时，更多的脏数据入缓存是下面这种情况：
1）请求A发起一个写操作，第一步淘汰了cache，如上图步骤1
2）请求A写数据库了，写入了最新的数据，如上图步骤2
3）请求B发起一个读操作，读cache，cache miss，如上图步骤3
4）请求B继续读DB，读的是从库，此时主从同步还没有完成，读出来一个脏数据，然后脏数据入cache，如上图步4
5）最后数据库的主从同步完成了，如上图步骤5
这种情况请求A和请求B的时序是完全没有问题的，是主动同步的时延（假设延时1秒钟）中间有读请求读从库读到脏数据导致的不一致。
那怎么来进行优化呢？
三、不一致优化思路
有同学说“那能不能先操作数据库，再淘汰缓存”，这个是不行的，在《缓存和数据库先操作谁》的文章中介绍过。
出现不一致的根本原因：
（1）单库情况下，服务层在进行1s的逻辑计算过程中，可能读到旧数据入缓存
（2）主从库+读写分离情况下，在1s钟主从同步延时过程中，可能读到旧数据入缓存
既然旧数据就是在那1s的间隙中入缓存的，是不是可以在写请求完成后，再休眠1s，再次淘汰缓存，就能将这1s内写入的脏数据再次淘汰掉呢？
答案是可以的。
写请求的步骤由2步升级为3步：
（1）先淘汰缓存
（2）再写数据库（这两步和原来一样）
（3）休眠1秒，再次淘汰缓存
这样的话，1秒内有脏数据如缓存，也会被再次淘汰掉，但带来的问题是：
（1）所有的写请求都阻塞了1秒，大大降低了写请求的吞吐量，增长了处理时间，业务上是接受不了的
再次分析，其实第二次淘汰缓存是“为了保证缓存一致”而做的操作，而不是“业务要求”，所以其实无需等待，用一个异步的timer，或者利用消息总线异步的来做这个事情即可：
写请求由2步升级为2.5步：
（1）先淘汰缓存
（2）再写数据库（这两步和原来一样）
（2.5）不再休眠1s，而是往消息总线esb发送一个消息，发送完成之后马上就能返回
这样的话，写请求的处理时间几乎没有增加，这个方法淘汰了缓存两次，因此被称为“缓存双淘汰”法。这个方法付出的代价是，缓存会增加1次cache miss（代价几乎可以忽略）。
而在下游，有一个异步淘汰缓存的消费者，在接收到消息之后，asy-expire在1s之后淘汰缓存。这样，即使1s内有脏数据入缓存，也有机会再次被淘汰掉。
上述方案有一个缺点，需要业务线的写操作增加一个步骤，有没有方案对业务线的代码没有任何入侵呢，是有的，这个方案在《细聊冗余表数据一致性》中也提到过，通过分析线下的binlog来异步淘汰缓存：
业务线的代码就不需要动了，新增一个线下的读binlog的异步淘汰模块，读取到binlog中的数据，异步的淘汰缓存。
提问：为什么上文总是说1s，这个1s是怎么来的？
回答：1s只是一个举例，需要根据业务的数据量与并发量，观察主从同步的时延来设定这个值。例如主从同步的时延为200ms，这个异步淘汰cache设置为258ms就是OK的。
四、总结
在“异常时序”或者“读从库”导致脏数据入缓存时，可以用二次异步淘汰的“缓存双淘汰”法来解决缓存与数据库中数据不一致的问题，具体实施至少有三种方案：
（1）timer异步淘汰（本文没有细讲，本质就是起个线程专门异步二次淘汰缓存）
（2）总线异步淘汰
（3）读binlog异步淘汰
【文章转载自微信公众号“架构师之路”】
58沈剑架构系列缓存与数据库一致性保证
...一致（2）不一致优化思路（3）如何保证数据库与缓存的一致性 一、需求缘起上一篇《缓存架构设计细节二三事》（点击查看）引起了广泛的讨论，其中有一个结论：当数据发生变化时，“先淘汰缓存，再修改数据库&rdquo... 查看详情
58沈剑架构系列细聊冗余表数据一致性
...表（3）正反冗余表谁先执行（4）冗余表如何保证数据的一致性 一、需求缘起互联网很多业务场景的数据量很大，此时数据库架构要进行水平切分，水平切分会有一个patitionkey，通过patitionkey的查询能够直接定位到库，但是非... 查看详情
58沈剑架构系列一分钟写好连接池
一、如何通过连接访问下游工程架构中有很多访问下游的需求，下游包括但不限于服务/数据库/缓存，其通讯步骤是为：（1）与下游建立一个连接（2）通过这个连接，收发请求（3）交互结束，关闭连接，释放资源 这个连接... 查看详情
58沈剑架构系列缓存架构设计细节二三事
本文主要讨论这么几个问题：（1）“缓存与数据库”需求缘起（2）“淘汰缓存”还是“更新缓存”（3）缓存和数据库的操作时序（4）缓存和数据库架构简析 一、需求缘起场景介绍缓存是一种提高系统读... 查看详情
58沈剑架构系列互联网架构，如何进行容量设计？
一，需求缘起互联网公司，这样的场景是否似曾相识： 场景一：pm要做一个很大的运营活动，技术老大杀过来，问了两个问题：（1）机器能抗住么？（2）如果扛不住，需要加多少台机器？ 场景二：系统设计阶段，技术... 查看详情
58沈剑架构系列一分钟了解负载均衡的一切
什么是负载均衡负载均衡(LoadBalance)是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。常见的负载均衡方案常见互联网分布式架构如上... 查看详情
58沈剑架构系列秒杀系统架构优化思路
一、秒杀业务为什么难做1）im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）；2）微博系统，每个人读你关注的人的数据，一个人读多个人的数据；3）秒杀系统，库存只有一份，所有人会在集... 查看详情
58沈剑架构系列线程数究竟设多少合理
一、需求缘起Web-Server通常有个配置，最大工作线程数，后端服务一般也有个配置，工作线程池的线程数量，这个线程数的配置不同的业务架构师有不同的经验值，有些业务设置为CPU核数的2倍，有些业务设置为CPU核数的8倍，有些... 查看详情
58同城沈剑：好的架构源于不停地衍变，而非设计
本次演讲主要会阐述，58同城从小流量、中等规模流量、大流量，到更大的流量过程中，架构是如何演进的？遇到了哪些问题？以及如何解决这些问题？好的架构不是设计出来的，而是演进出来的对很多创业公司而言，很难在初... 查看详情
[2016-03-18][架构]读《58同城沈剑：好的架构不是设计出来的，而是演进出来的》
文章摘录：———————————————————————-58同城从小流量、中等规模流量、大流量，到更大的流量过程中，架构是 查看详情
kafka系列之1—kafka的总体认识
...统4.存储逻辑层的高并发保证5.isr机制降低了保证分布式一致性的代价1.非中心的架构模型我们知道，在分布式系统的架构类型里，既有主从式的架构，也有非中心式的架构，像hadoop和hbase都采用了主从式的架构模型，主从式的架... 查看详情
kafka系列之1—kafka的总体认识
...统4.存储逻辑层的高并发保证5.isr机制降低了保证分布式一致性的代价1.非中心的架构模型我们知道，在分布式系统的架构类型里，既有主从式的架构，也有非中心式的架构，像hadoop和hbase都采用了主从式的架构模型，主从式的架... 查看详情
缓存和数据库不一致出现的原因及其解决
...写出现并发。理论上，給cache设置过期时间，是保证最终一致性到解决方案。这种方案下，写操作以数据库为准。更新cache失败，只要到了过期时间，后面的读请求会从数据库中读取新值存入cache。不过，实际开发中只设过期时间... 查看详情
mha架构
MHA完成主从切换超高效 保证数据的一致性，达到真正意义的高可用 MHA提供了什么功能？ 监控主数据库服务器是否可用 当主DB不可用时，从多个从服务器中选举新的 主数据库服务器提供了主从切换和故障... 查看详情
浅析分布式主从架构下数据一致性问题
...态，但是这个常见的策略会产生一系列的分布式数据一致性问题。通常我们使用主从架构，主要是处于以下几个目的：提高服务的容错性，即使一个节点崩溃了，还存在多个节点可以对外提供服务 查看详情
浅析分布式主从架构下数据一致性问题
...态，但是这个常见的策略会产生一系列的分布式数据一致性问题。通常我们使用主从架构，主要是处于以下几个目的：提高服务的容错性，即使一个节点崩溃了，还存在多个节点可以对外提供服务 查看详情
浅析分布式主从架构下数据一致性问题
...态，但是这个常见的策略会产生一系列的分布式数据一致性问题。通常我们使用主从架构，主要是处于以下几个目的：提高服务的容错性，即使一个节点崩溃了，还存在多个节点可以对外提供服务 查看详情
负载均衡基本介绍
参考技术A【负载均衡架构部分转自】58沈剑[架构师之路](https://mp.weixin.qq.com/s负载均衡：是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀... 查看详情