开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第45天，点击查看活动详情
引入缓存之后，你就会面临一个问题：之前数据只存在数据库中，现在要放到缓存中读取，具体要怎么存呢？
最简单直接的方案是「全量数据刷到缓存中」：
●数据库的数据，全量刷入缓存（不设置失效时间）
●写请求只更新数据库，不更新缓存
●启动一个定时任务，定时把数据库的数据，更新到缓存中
这个方案的优点是，所有读请求都可以直接「命中」缓存，不需要再查数据库，性能非常高。
但缺点也很明显，有 2 个问题：
1缓存利用率低：不经常访问的数据，还一直留在缓存中
2数据不一致：因为是「定时」刷新缓存，缓存和数据库存在不一致（取决于定时任务的执行频率）
如何保证缓存和数据库数据的一致性？要想保证缓存和数据库「实时」一致，那就不能再用定时任务将数据库数据刷新进缓存了。
所以，当数据发生更新时，我们不仅要操作数据库，还要一并操作缓存。具体操作就是：
●方案一：双写模式：修改一条数据时，先更新数据库，之后更新缓存
●方案二：失效模式：修改一条数据时，先更新数据库，之后删除缓存。
●方案三：双删模式：再方案二的基础之上，写线程A隔一段时间再一次删除缓存，防止缓存被读线程B种回旧值
双写模式：写写并发带来新问题
假设我们采用「先更新数据库，再更新缓存」的方案，并且两步都可以「成功执行」的前提下，如果存在并发，情况会是怎样的呢？
有线程 A 和线程 B 两个线程，需要更新「同一条」数据，会发生这样的场景
类似于丢失修改，只不过这里丢失的是线程2的修改
区别于MySQL并发事务当中的丢失修改，丢失的是并发1的修改
1线程 A 更新数据库（X = 1）
2线程 B 更新数据库（X = 2）
3线程 B 更新缓存（X = 2）
4线程 A 更新缓存（X = 1）
最终 X 的值在缓存中是 1，在数据库中是 2，发生不一致。
同样地，采用「先更新缓存，再更新数据库」的方案，也会有类似问题，这里不再详述。
除此之外，我们从「缓存利用率」的角度来评估这个方案，也是不太推荐的。
●这是因为每次数据发生变更，都「无脑」更新缓存，但是缓存中的数据不一定会被「马上读取」，这就会导致缓存中可能存放了很多不常访问的数据，浪费缓存资源。
●而且很多情况下，写到缓存中的值，并不是与数据库中的值一一对应的，很有可能是先查询数据库，再经过一系列「计算」得出一个值，才把这个值才写到缓存中。
由此可见，这种「更新数据库 + 更新缓存」的方案，不仅缓存利用率不高，还会造成机器性能的浪费。
失效模式：写写读并发带来新问题
这次来了三个线程：
●一个写线程，线程A
●一个写线程，线程B
●一个读线程，线程B
概念澄清：
●旧DB：线程A写的DB
●新DB：线程B写的DB
可能发生的意外：
1线程A正常先写DB后删缓存
2线程B是个超级耗时的操作还没写好数据库，线程C就来读了
3第一个关键点：线程C来读缓存，由于缓存被A删除了读不到只能读DB，此时的DB是线程A修改的值，相当于旧DB
4线程C读完旧DB之后，线程B终于写好了新DB，写好之后立刻删除缓存
5第二个关键点：线程C读完旧DB自然更新缓存为旧的DB值，但读线程更新缓存的时间点在步骤4之后，最终导致缓存当中是旧DB值，数据库当中是新DB值，产生了不一致
缓存设置过期时间，定期更新。最终一致性，其实我们也可以接受
双删模式||延迟删除
看到了么？在缓存失效模式当中缓存有可能被回种了「旧值」。那怎么解决这类问题呢？
最有效的办法就是，再次把缓存删掉
●或者不能立即删，而是需要「延迟删」，延迟时间要大于线程 B 读取数据库 + 写入缓存的时间，但是，这个时间在分布式和高并发场景下，其实是很难评估的。很多时候，我们都是凭借经验大致估算这个延迟时间，例如延迟 1-5s，只能尽可能地降低不一致的概率。
怎么去通知操作缓存【第二步操作】
重试
是的，其实这里我们也可以这样做。
无论是先操作缓存，还是先操作数据库，但凡后者执行失败了，我们就可以发起重试，尽可能地去做「补偿」。
那这是不是意味着，只要执行失败，我们「无脑重试」就可以了呢？
答案是否定的。现实情况往往没有想的这么简单，失败后立即重试的问题在于：
●立即重试很大概率「还会失败」
●「重试次数」设置多少才合理？
●重试会一直「占用」这个线程资源，无法服务其它客户端请求
看到了么，虽然我们想通过重试的方式解决问题，但这种「同步」重试的方案依旧不严谨。
那更好的方案应该怎么做？
答案是：异步重试。什么是异步重试？
异步重试
其实就是把重试请求写到「消息队列」中，然后由专门的消费者来重试，直到成功。
或者更直接的做法，为了避免第二步执行失败，我们可以把操作缓存这一步，直接放到消息队列中，由消费者来操作缓存。
这里也是学术上常讲的旁路缓存模式 Cache Aside Pattern
下面单独对 Cache Aside Pattern（旁路缓存模式） 来聊聊。
Cache Aside Pattern 中遇到写请求是这样的：更新 DB，然后直接删除 cache 。
增加 cache 更新重试机制（常用）： 如果 cache 服务当前不可用导致缓存删除失败的话，我们就隔一段时间进行重试，重试次数可以自己定。如果多次重试还是失败的话，我们可以把当前更新失败的 key 存入队列中，等缓存服务可用之后，再将缓存中对应的 key 删除即可。
到这里你可能会问，写消息队列也有可能会失败啊？而且，引入消息队列，这又增加了更多的维护成本，这样做值得吗？这个问题很好，但我们思考这样一个问题：如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目「重启」了，那这次重试请求也就「丢失」了，那这条数据就一直不一致了。
所以，这里我们必须把重试或第二步操作放到另一个「服务」中，这个服务用「消息队列」最为合适。这是因为消息队列的特性，正好符合我们的需求：
●消息队列保证可靠性：写到队列中的消息，成功消费之前不会丢失（重启项目也不担心）
●消息队列保证消息成功投递：下游从队列拉取消息，成功消费后才会删除消息，否则还会继续投递消息给消费者（符合我们重试的场景）
至于写队列失败和消息队列的维护成本问题：
●写队列失败：操作缓存和写消息队列，「同时失败」的概率其实是很小的
●维护成本：我们项目中一般都会用到消息队列，维护成本并没有新增很多
所以，引入消息队列来解决这个问题，是比较合适的。这时架构模型就变成了这样：
