更新缓存的正确姿势（先更新缓存还是先更新数据库）

目录

1.更新缓存的三种模式

1.1 Cache Aside

1.1.1 先更新DB，后更新缓存

?1.1.2 先更新缓存，后更新DB

1.1.3 先删除缓存，再更新DB

1.1.4 先更新DB，再删除缓存（业界推荐方案）

1.2 Read/Write Through

1.3 ReadThrough/Write Behind

2.三种缓存模式小结

1.更新缓存的三种模式

        引入缓存势必会导致数据的一致性问题（因为分别存放到缓存以及DB），那么在数据更新时，缓存和DB都得更新，并且更新时序的不同会导致不同的结果。关于数据更新目前业界已经沉淀了Cache Aside Pattern，Read/Write through， Write Behind Caching等三种方式。

        Cache Aside ：同时更新缓存和数据库；

        Read/Write Through：先更新缓存，缓存负责同步更新数据库；

        Write Behind Caching：先更新缓存，缓存定时异步更新数据库。这三种模式各有优劣，可以根据业务场景选择使用。

1.1 Cache Aside

        应用直接去缓存中找数据，命中缓存则直接返回，如果未命中缓存，则需要先去数据库中查询数据，并将查询到的数据存储到缓存中。

        读策略：

1. 程序需要判断缓存中是否已经存在数据。
2. 当缓存中已经存在数据，则直接从缓存中返回数据
3. 当缓存中不存在数据，则先从数据库里读取数据，并且存入缓存，然后返回数据

        写策略：

这里存在两个问题：

1. 先更新DB还是先更新缓存/li>
2. 是更新缓存还是删除缓存/li>

针对问题1，我们有两种方案：

1. 先更新DB，后更新缓存         
2. 先更新缓存，后更新DB   

针对问题2，我们也有两种方案：

1. 先删除缓存，再更新DB        
2. 先删除DB，再更新缓存             

接下来我们逐条分析

1.1.1 先更新DB，后更新缓存

        如图，并发更新会造成DB和缓存数据不一致。

        如图，和上图一样，并发双写会导致数据不一致的问题。

1.1.3 先删除缓存，再更新DB

        上述我们看到，更新缓存在并发双写的情况下是不安全的，那如果改成删除缓存呢：因为delete操作是天然幂等的，所以并发双写不会对删除缓存的方案产生影响，但如果是并发读写呢们看下图：

         可以看到，在并发读写下，还是会存在数据不一致的问题。可以考虑通过异步双删(通过两次删除来解决并发读造成的脏数据)或者给数据设置过期时间来解决。异步双删代码：

1.1.4 先更新DB，再删除缓存（业界推荐方案）

         假设缓存刚好到期失效时，读请求从db中读取数据，写请求更新完数据后再失效缓存后，读请求将旧数据存入到缓存中，这种情况也会导致脏数据的问题。实际上这种情况发生的概率很低，要发生这种情况的前提条件是写数据库要先于读数据库完成，一般而言读数据库相比于写数据库要耗时更短，这种前提条件成立的概率很低。针对这种情况，也可以采用上面所说的异步双删策略以及过期失效的方式来避免。

1.2 Read/Write Through

读数据策略：

        当数据发生更新时，查询缓存时更新缓存，然后由缓存层同步的更新数据库

写数据策略：

        当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由Cache自己同步更新数据库。

        简单来说，该模式将缓存作为主要的数据源，而数据库对于应用程序是透明的，更新数据库的任务交给缓存来处理，应用程序直接和缓存服务打交道即可。

1.3 ReadThrough/Write Behind

读数据策略：

        当数据发生更新时，查询缓存时更新缓存，然后由缓存层同步的更新数据库

写数据策略：

        当数据更新的时候直接更新缓存数据，然后建立异步任务去更新数据库。

        这种异步方式请求响应会很快，系统的吞吐量会明显提升。但是因为是异步更新数据库，数据一致性的保障就会变弱，如果更新数据库失败则会永远的造成系统脏数据，需要很精细设计系统重试的策略，另外如果异步服务宕机的话，还要考虑更新的数据如何持久化，服务重启后能够迅速恢复。在更新数据库时，由于并发多任务的存在，还需要考虑并发写是否会造成脏数据的问题。

2.三种缓存模式小结

Cache Aside：

        优点：缓存仅仅保存被请求的数据，属于懒加载模式(Lazy Loading)，避免了任何数据都被写入缓存造成缓存频繁更新

        缺点：

1. 当发生缓存未命中的情况时响应较慢。
2. 实现逻辑都在应用程序中，如果后端拆分微服务，会造成代码冗余

        适用于：流量和并发不高的常规性缓存

Read/Write Through：

        优点：        

1. 缓存不存在脏数据
2. 读取效率更高，因为写操作每次都会更新缓存，所以提高了读操作命中缓存的概率
3. 缓存单独抽成服务，应用程序的逻辑相对简单

        缺点：对于写多读少的应用不是很合适，数据可能更改了很多次，每次都写入缓存却没有被读取，造成了大量写入延迟时间的浪费。

        适用于：流量和并发较高的缓存场景

ReadThrough/Write Behind：

        优点：

1. 读操作和写操作效率很高，因为都是直接从缓存中读取和写入。
2. 对于数据库不可用的情况有一定的容忍度，即使数据库暂时不可用，系统也整体可用，当数据库之后恢复的时候，再将数据写入数据库。

        缺点：有数据丢失的风险，如果缓存挂掉而数据没有及时写到数据库中，那么缓存中的有些数据将永久丢失。

        适用于：秒杀等频繁写入的场景

参考资料：https://zhuanlan.zhihu.com/p/96095635

                  Redis在电商系统中的正确打开方式 – 简书

                  掘金

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树数据库组成表31260 人正在系统学习中