缓存一致性

人生如逆旅，我亦是行人 ---------- 苏轼

缓存在业务系统中常常扮演着重要角色，但是在选择采用缓存时一般都会遇到一个很重要的问题如何保持缓存和数据库的一致性？

首先要考虑的一个问题是对于在进行更新操作时，我们是删除还是更新缓存？

是更新缓存还是删除缓存

在对数据进行变更时，对于缓存有两种处理方法，分别是更新和删除。一般这个时候我们会选择删除缓存，原因是更新缓存可能会导致脏数据问题，看下面的例子：

①A更新了数据库

②B更新了数据库

③B更新了缓存

④A更新了缓存

再这种情况下最新的数据会被老数据给覆盖了，导致查询的时候可能会查到脏数据，而删除缓存则不会存在这个问题。

我们是应该先删除缓存还是应该先更新数据库呢？

先删除缓存再更新数据库

对于先删除再更新数据库会存在一个问题，在删除完缓存之后还没来得及更新数据库中的数据，此时有一个查询请求过来会把旧数据重新加载到缓存中，会导致脏数据。针对于这种情况有一种解决办法：延时双删。所谓的延时双删就是先删除一次缓存，然后更新数据库，接着睡眠一定时间（比如1s)，再删除一次缓存。为了能尽可能的降低脏数据的可能性，对于睡眠时间一般定为读数据业务逻辑的耗时基础上，加几百ms即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。同时可以设定一个缓存过期时间，即使产生脏数据，也能尽量减少影响。

先更新数据库再删除缓存

如果我们先更新数据库再删除缓存，可能删除缓存的时候会失败，导致存在脏数据。一般的解决方法是采用异步重试的方式，比如使用mq。不过如果这种情况下使用mq会对业务有入侵且逻辑偏重。在数据库采用mysql的时候，可以订阅bin日志，采用异步重试的方式删除缓存。

介绍几种经典的缓存一致性模型。

Cache Aside

查询：先查缓存，缓存失效，则查询数据库，并更新缓存

更新：先更新数据库，然后删除缓存

Read Through/Write Through

查询：先查缓存，缓存失效，则查询数据库，并更新缓存 （相较于Cache Aside是有一个专门的模块提供给业务侧查询，业务侧不关心数据是从缓存还是从数据库中读取）

更新：先更新缓存，再更新数据库

Write Behind

查询：先查缓存，缓存失效，则查询数据库（注意：不更新缓存）

更新：先更新缓存，由缓存异步更新数据库

缓存穿透和缓存雪崩

• 缓存穿透：大量的key不存在，在缓存中查不到数据，直接去查询数据库，导致数据库最终不可用。

  避免方法：采用布隆过滤器过滤无效的key，减少数据库压力

• 缓存击穿：某一个热点key失效了，导致大量请求直接到达数据库，最终导致数据库不可用

  避免方法：①缓存中增加互斥锁机制，确保只有一个请求达到数据库，并更新缓存，其它的等待重试。

  ​ ②提前异步更新cache

• 缓存雪崩：缓存中的大量key同一时间失效，导致请求都直接到数据库，最终数据库不可用

  避免方法：①缓存中增加互斥锁机制，确保只有一个请求达到数据库，并更新缓存，其它的等待重试。

  ​ ②缓存过期时间随机化，避免同一时间失效。有一个业务实践方案是0.03%的请求会直接到达数据库，提前更新缓存，让缓存一直不失效。

  ​ ③熔断，限流，降级。

综合来说，缓存是一把提升系统效能的利器，但是同时也会增加系统的复杂性。系统中增加了缓存之后就需要考虑考虑缓存本身的可用性，需要给缓存增加相应的配套措施，比如监控告警，熔断，降级，限流，演习，预热等，保证系统不出错。没有什么东西是万能的，设计系统时更多的是一种折中选择。