分布式之数据库和缓存双写一致性方案解析.docxVIP

分布式之数据库和缓存双写全都性方案解析 为什么写这篇文章？ 首先，缓存由于其高并发和高功能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是依据下图的流程来进行业务操作。但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库，其实大家存在很大的争议。目前没有一篇全面的博客，对这几种方案进行解析。于是博主战战兢兢，顶着被大家喷的风险，写了这篇文章。 文章结构 本文由以下三个部分组成1、讲解缓存更新策略2、对每种策略进行缺点分析3、针对缺点给出改进方案 注释 先做一个说明，从理论上来说，给缓存设置过期时间，是保证最终全都性的处理方案。这种方案下，我们可以对存入缓存的数据设置过期时间，全部的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说假如数据库写成功，缓存更新失败，那么只需到达过期时间，则后面的读恳求自然会从数据库中读取新值然后回填缓存。因而，接下来争辩的思路不依靠于给缓存设置过期时间这个方案。在这里，我们争辩三种更新策略： 先更新数据库，再更新缓存 先删除缓存，再更新数据库 先更新数据库，再删除缓存 应当没人问我，为什么没有先更新缓存，再更新数据库这种策略。 (1)先更新数据库，再更新缓存 这套方案，大家是普遍反对的。为什么呢？有如下两点缘由。缘由一（线程平安角度）同时有恳求A和恳求B进行更新操作，那么会消灭（1）线程A更新了数据库（2）线程B更新了数据库（3）线程B更新了缓存（4）线程A更新了缓存这就消灭恳求A更新缓存应当比恳求B更新缓存早才对，但是由于网络等缘由，B却比A更早更新了缓存。这就导致了脏数据，因而不考虑。缘由二（业务场景角度）有如下两点：（1）假如你是一个写数据库场景比较多，而读数据场景比较少的业务需求，接受这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，铺张功能。（2）假如你写入数据库的值，并不是直接写入缓存的，而是要经过一系列简单的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是铺张功能的。明显，删除缓存更为适合。 接下来争辩的就是争议最大的，先删缓存，再更新数据库。还是先更新数据库，再删缓存的问题。 (2)先删缓存，再更新数据库 该方案会导致不全都的缘由是。同时有一个恳求A进行更新操作，另一个恳求B进行查询操作。那么会消灭如下情形:（1）恳求A进行写操作，删除缓存（2）恳求B查询发觉缓存不存在（3）恳求B去数据库查询得到旧值（4）恳求B将旧值写入缓存（5）恳求A将新值写入数据库上述情况就会导致不全都的情形消灭。而且，假如不接受给缓存设置过期时间策略，该数据永久都是脏数据。那么，如何处理呢？接受延时双删策略伪代码如下 转化为中文描述就是（1）先淘汰缓存（2）再写数据库（这两步和原来一样）（3）休眠1秒，再次淘汰缓存这么做，可以将1秒内所形成的缓存脏数据，再次删除。针对上面的情形，读者应当自行评估本人的项目的读数据业务规律的耗时。然后写数据的休眠时间则在读数据业务规律的耗时基础上，加几百ms即可。这么做的目的，就是确保读恳求结束，写恳求可以删除读恳求形成的缓存脏数据。ok，在这种情况下，形成数据不全都的缘由如下，还是两个恳求，一个恳求A进行更新操作，另一个恳求B进行查询操作。（1）恳求A进行写操作，删除缓存（2）恳求A将数据写入数据库了，（3）恳求B查询缓存发觉，缓存没有值（4）恳求B去从库查询，这时，还没有完成主从同步，因而查询到的是旧值（5）恳求B将旧值写入缓存（6）数据库完成主从同步，从库变为新值上述情形，就是数据不全都的缘由。还是使用双删延时策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。ok，那就将其次次删除作为异步的。本人起一个线程，异步删除。这样，写的恳求就不用沉睡一段时间后了，再前往。这么做，加大吞吐量。这是个格外好的问题，由于其次次删除失败，就会消灭如下情形。还是有两个恳求，一个恳求A进行更新操作，另一个恳求B进行查询操作，为了便利，假设是单库：（1）恳求A进行写操作，删除缓存（2）恳求B查询发觉缓存不存在（3）恳求B去数据库查询得到旧值（4）恳求B将旧值写入缓存（5）恳求A将新值写入数据库（6）恳求A试图去删除恳求B写入对缓存值，结果失败了。ok,这也就是说。假如其次次删除缓存失败，会再次消灭缓存和数据库不全都的问题。具体处理方案，且看博主对第(3)种更新策略的解析。 (3)先更新数据库，再删缓存 首先，先说一下。老外提出了一个缓存更新套路，名为《Cache-Aside pattern》。其中就指出 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓