什么是一致性

“数据一致”一般指的是：缓存中有数据，缓存的数据值=数据库中的值。但根据缓存中是有数据为依据，则“一致”可以包含两种情况：
1）缓存中有数据，缓存的数据值=数据库中的值。
2）缓存中本没有数据，数据库中的值=最新值（有请求查询数据库时，会将数据写入缓存，则变为上面的“一致”状态）。
“数据不一致”：缓存的数据值≠数据库中的值；缓存或者数据库中存在旧值，导致其他线程读到旧数据。

针对缓存更新问题，提出了一个旁路缓存的缓存更新套路，这个策略分为以下三种场景：
1）失效：应用程序先从缓存取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
2）命中：应用程序从缓存中取数据，取到后返回。
3）更新：先把数据存到数据库中，成功后，再让缓存失效。
不管是先删缓存再更新数据库还是先更新数据库再删缓存，如果删除缓存失败了都会导致缓存跟数据不一致问题！
[图片上传失败...(image-b48458-1658132460557)]

这里我们总结出六种方案，如下图
根据是否接收写请求，可以把缓存分成读写缓存和只读缓存。
只读缓存：只在缓存进行数据查找，即使用“更新数据库+删除缓存”策略。
读写缓存：需要在缓存中对数据进行增删改查，即使用“更新数据库+更新缓存”策略。

先写MySQL，再写Redis

请求 A、B 都是先写 MySQL，然后再写 Redis，在高并发情况下，如果请求 A 在写 Redis 时卡了一会，请求 B 已经依次完成数据的更新，就会出现图中的问题。

先写Redis，再写MySQL

请求 A 先删除缓存，可能因为卡顿，数据一直没有更新到 MySQL，导致两者数据不一致。
这种情况出现的概率比较大，因为请求 A 更新 MySQL 可能耗时会比较长，而请求 B 的前两步都是查询，会非常快。

先删除 Redis，再写 MySQL，再删除 Redis

先写 MySQL，通过 Binlog，异步更新 Redis

这种方案，主要是监听 MySQL 的 Binlog，然后通过异步的方式，将数据更新到 Redis，这种方案有个前提，查询的请求，不会回写 Redis。
这个方案，会保证 MySQL 和 Redis 的最终一致性，但是如果中途请求 B 需要查询数据，如果缓存无数据，就直接查 DB；如果缓存有数据，查询的数据也会存在不一致的情况。所以这个方案，是实现最终一致性的终极解决方案，但是不能保证实时性。

1、先写 Redis，再写 MySQL
这种方案，我肯定不会用，万一 DB 挂了，你把数据写到缓存，DB 无数据，这个是灾难性的；
我之前也见同学这么用过，如果写 DB 失败，对 Redis 进行逆操作，那如果逆操作失败呢，是不是还要搞个重试？
2、先写 MySQL，再写 Redis
对于并发量、一致性要求不高的项目，很多就是这么用的，我之前也经常这么搞，但是不建议这么做；
当 Redis 瞬间不可用的情况，需要报警出来，然后线下处理。
3、先删除 Redis，再写 MySQL
这种方式，我还真没用过，直接忽略吧。
4、先删除 Redis，再写 MySQL，再删除 Redis
这种方式虽然可行，但是感觉好复杂，还要搞个消息队列去异步删除 Redis。
5、先写 MySQL，再删除 Redis
比较推荐这种方式，删除 Redis 如果失败，可以再多重试几次，否则报警出来；
这个方案，是实时性中最好的方案，在一些高并发场景中，推荐这种。
6、先写 MySQL，通过 Binlog，异步更新 Redis
对于异地容灾、数据汇总等，建议会用这种方式，比如 binlog + kafka，数据的一致性也可以达到秒级；
纯粹的高并发场景，不建议用这种方案，比如抢购、秒杀等。

实时一致性方案：采用“先写 MySQL，再删除 Redis”的策略，这种情况虽然也会存在两者不一致，但是需要满足的条件有点苛刻，所以是满足实时性条件下，能尽量满足一致性的最优解。
最终一致性方案：采用“先写 MySQL，通过 Binlog，异步更新 Redis”，可以通过 Binlog，结合消息队列异步更新 Redis，是最终一致性的最优解。

只读缓存策略

只读缓存：新增数据时，直接写入数据库；更新（修改/删除）数据时，先删除缓存。后续访问这些增删改的数据时，会发生缓存缺失，进而查询数据库，更新缓存。
新增数据时 ，写入数据库；访问数据时，缓存缺失，查数据库，更新缓存（始终是处于“数据一致”的状态，不会发生数据不一致性问题)

更新（修改/删除）数据时，会有个时序问题：更新数据库与删除缓存的顺序（这个过程会发生数据不一致性问题）。
在更新数据的过程中，可能会有如下问题：
1）无并发请求下，其中一个操作失败的情况。
2）并发请求下，其他线程可能会读到旧值。
因此，要想达到数据一致性，需要保证两点：
1）无并发请求下，保证A和B步骤都能成功执行。
2）并发请求下，在A和B步骤的间隔中，避免或消除其他线程的影响。
接下来，我们针对有/无并发场景，进行分析并使用不同的策略。
1）无并发情况
无并发请求下，在更新数据库和删除缓存值的过程中，因为操作被拆分成两步，那么就很有可能存在“步骤1成功，步骤2失败” 的情况发生（由于单线程中步骤1和步骤2是串行执行的，不太可能会发生 “步骤2成功，步骤1失败” 的情况）。
(1) 先删除缓存，再更新数据库

此外，还可以通过延时双删进行保障：在线程A更新完数据库值以后，让它先sleep一小段时间，确保线程B能够先从数据库读取数据，再把缺失的数据写入缓存，然后，线程A再进行删除。后续其它线程读取数据时，发现缓存缺失，会从数据库中读取最新值。

redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)
sleep时间：在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，以此为基础来进行估算。
注意：如果难以接受sleep这种写法，可以使用延时队列进行替代。

先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力，也就是缓存穿透的问题。针对缓存穿透问题，可以用缓存空结果、布隆过滤器进行解决。

(2) 先更新数据库，再删除缓存

如果线程A更新了数据库中的值，但还没来得及删除缓存值，线程B就开始读取数据了，那么此时，线程B查询缓存时，发现缓存命中，就会直接从缓存中读取旧值。其本质也是，本应后发生的“B线程-读请求”先于“A线程-删除缓存”执行并返回了。
凭借经验发送「延迟消息」到队列中，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率。

b.订阅binlog，异步删除

通过数据库的binlog来异步淘汰key，利用工具(canal)将binlog日志采集发送到MQ中，然后通过ACK机制确认处理删除缓存。

c.删除消息写入数据库

通过比对数据库中的数据，进行删除确认 先更新数据库再删除缓存，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力，也就是缓存穿透的问题。针对缓存穿透问题，可以用缓存空结果、布隆过滤器进行解决。

更新数据时，加写锁；查询数据时，加读锁。

优先使用“先更新数据库再删除缓存”的执行时序，原因主要有两个：

1）先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力。

2）业务应用中读取数据库和写缓存的时间有时不好估算，进而导致延迟双删中的sleep时间不好设置。
针对读写缓存（更新数据库+更新缓存）
读写缓存：增删改在缓存中进行，并采取相应的回写策略，同步数据到数据库中。

同步直写：使用事务，保证缓存和数据更新的原子性，并进行失败重试（如果Redis本身出现故障，会降低服务的性能和可用性）

异步回写：写缓存时不同步写数据库，等到数据从缓存中淘汰时，再写回数据库（没写回数据库前，缓存发生故障，会造成数据丢失）

该策略在秒杀场中有见到过，业务层直接对缓存中的秒杀商品库存信息进行操作，一段时间后再回写数据库。

一致性：同步直写>异步回写，因此，对于读写缓存，要保持数据强一致性的主要思路是：利用同步直写，同步直写也存在两个操作的时序问题：更新数据库和更新缓存。
无并发情况
强一致性策略
上述策略只能保证数据的最终一致性。要想做到强一致，最常见的方案是2PC、3PC、Paxos、Raft这类一致性协议，但它们的性能往往比较差，而且这些方案也比较复杂，还要考虑各种容错问题。如果业务层要求必须读取数据的强一致性，可以采取以下策略：

1）暂存并发读请求

在更新数据库时，先在Redis缓存客户端暂存并发读请求，等数据库更新完、缓存值删除后，再读取数据，从而保证数据一致性。

2）串行化

读写请求入队列，工作线程从队列中取任务来依次执行

（1）修改服务Service连接池，id取模选取服务连接，能够保证同一个数据的读写都落在同一个后端服务上。

（2）修改数据库DB连接池，id取模选取DB连接，能够保证同一个数据的读写在数据库层面是串行的。

（3）使用Redis分布式读写锁

将淘汰缓存与更新库表放入同一把写锁中，与其它读请求互斥，防止其间产生旧数据。读写互斥、写写互斥、读读共享，可满足读多写少的场景数据一致，也保证了并发性。并根据逻辑平均运行时间、响应超时时间来确定过期时间。
public void write() {
    Lock writeLock = redis.getWriteLock(lockKey);
    writeLock.lock();
    try {
        redis.delete(key);
        db.update(record);
    } finally {
        writeLock.unlock();
public void read() {
    if (caching) {
        return;
    // no cache
    Lock readLock = redis.getReadLock(lockKey);
    readLock.lock();
    try {
        record = db.get();
    } finally {
        readLock.unlock();
    redis.set(key, record);
较为通用的一致性策略拟定：

在并发场景下，使用“更新数据库+更新缓存”需要用分布式锁保证缓存和数据一致性，且可能存在“缓存资源浪费”和“机器性能浪费”的情况；一般推荐使用“更新数据库+删除缓存”的方案。如果根据需要，热点数据较多，可以使用“更新数据库+更新缓存”策略。
在“更新数据库+删除缓存”的方案中，推荐使用推荐用“先更新数据库，再删除缓存”策略，因为先删除缓存可能会导致大量请求落到数据库，而且延迟双删的时间很难评估。
在“先更新数据库，再删除缓存”策略中，可以使用“消息队列+重试机制”的方案保证缓存的删除。并通过“订阅binlog”进行缓存比对，加上一层保障。
此外，需要通过初始化缓存预热、多数据源触发、延迟消息比对等策略进行辅助和补偿。【多种数据更新触发源：定时任务扫描，业务系统MQ、binlog变更MQ，相互之间作为互补来保证数据不会漏更新】
需要注意的其他问题
1）k-v大小的合理设置

Redis key大小设计：由于网络的一次传输MTU最大为1500字节，所以为了保证高效的性能，建议单个k-v大小不超过1KB，一次网络传输就能完成，避免多次网络交互；k-v是越小性能越好。

Redis热key：当业务遇到单个读热key，通过增加副本来提高读能力或是用hashtag把key存多份在多个分片中。

当业务遇到单个写热key，需业务拆分这个key的功能，属于设计不合理-当业务遇到热分片，即多个热key在同一个分片上导致单分片cpu高，可通过hashtag方式打散。

2）避免其他问题导致缓存服务器崩溃，进而简直导致数据一致性策略失效缓存穿透、缓存击穿、缓存雪崩、机器故障等问题
先写 Redis，再写 MySQL
这种方案，我肯定不会用，万一 DB 挂了，你把数据写到缓存，DB 无数据，这个是灾难性的；

我之前也见同学这么用过，如果写 DB 失败，对 Redis 进行逆操作，那如果逆操作失败呢，是不是还要搞个重试？
先写 MySQL，再写 Redis
对于并发量、一致性要求不高的项目，很多就是这么用的，我之前也经常这么搞，但是不建议这么做；

当 Redis 瞬间不可用的情况，需要报警出来，然后线下处理。
先删除 Redis，再写 MySQL
这种方式，我还真没用过，直接忽略吧。
先删除 Redis，再写 MySQL，再删除 Redis
这种方式虽然可行，但是感觉好复杂，还要搞个消息队列去异步删除 Redis。
先写 MySQL，再删除 Redis