缓存与数据库双写一致性几种策略分析

旧城等待， 2024-03-23 15:13 33阅读 0赞

#### **一、背景** ####

在高并发场景中，为防止大量请求直接访问数据库，缓解数据库压力，常用的方式一般会增加缓存层起到缓冲作用，减少数据库压力。引入缓存，就会涉及到缓存与数据库中数据如何保持一致性问题，本文将对几种缓存与数据库保证数据一致性的使用方式进行分析。**为保证高并发性能，以下分析场景不考虑执行的原子性及加锁等强一致性要求的场景，仅追求最终一致性。**

#### **二、读取过程** ####

![36a815ad0850b37225239195a3bdfbdd.png][]

• 读缓存

• 如果缓存里没有值，那就读取数据库的值

• 同时把这个值写进缓存中

#### **三、更新过程** ####

更新操作有多种策略，各有优劣，主要针对此场景进行分析

策略 1：先更新 db，再删除缓存（常用的 Cache-Aside Pattern 旁路缓存）

![322e746b5e6c66467e3e62c10f19ec61.png][]

问题：

1. 如果更新 db 成功，删缓存失败，将导致数据不一致

2. 极端场景，请求 A 读，B 写

1) 此时缓存刚好失效 2）A 查库得到旧值 3）B 更新 DB 成功

4）B 删除缓存 5）A 将查到的旧值更新到缓存中

此场景的发生需要步骤 2）查 db 始终慢于 3）的更新 db，才能导致 4）先于 5）执行，通常 db 的查询是要快于写入的，所以此极端场景的产生过于严格，不易发生

策略 2：先更新 db, 再更新缓存

![05c37376b751f8791135923c20262d87.png][]

问题：

1. 并发更新场景下，更新缓存会导致数据不一致

2. 根据读写比，考虑是否有必要频繁同步更新缓存，而且，如果构造缓存中数据过于复杂，或者数据更新频繁，但是读取并不频繁的情况，还会造成不必要的性能损耗

此种方式不推荐

策略 3: 先更新缓存，再更新 db

![72eff49b5df2cf82b5dc4cb8200e35e8.png][]

同上，不推荐

策略 4：先删缓存，再更新 db

![64f8745cab057052f330c3ac5312e4f2.png][]

先删缓存，虽然解决了策略 1 中，后删缓存如果失败的场景，但也会发生不一致的问题

例如：请求 A 删除缓存，这时请求 B 来查，就会击穿到数据库，B 读取到旧的值后写入缓存，A 正常更新 db, 由于时间差导致数据不一致的情况

策略 5：缓存延时双删

![52d07b699dcbc9e696795ff731ded682.png][]

该策略兼容了策略 1 和策略 4, 解决了先删缓存还是后删缓存的问题，如策略 1 中，更新 db 后删缓存失败和策略 4 中的不一致场景，该策略可以将延时时间内（比如延时 10ms）所造成的缓存脏数据，再次删除。但是，如果延时删缓存失败，策略 4 中不一致问题还会发生，同时延时的实现，如创建线程，或者引入 mq 异步，可能会增加系统复杂度问题。

策略 6：变种双删，前置缓存过期时间

![81b17e3be77444a41e7f2de1536b5c01.png][]

该策略针对策略 1 中后删缓存失败的场景，前置一层缓存数据过期时间（具体时间根据自身系统本身评估，如可覆盖 db 读写耗时或一致性容忍度等），更新 db 后就算删缓存失败，在 expire 时间后也能保证缓存中无数据。同时，前置 expire 失败，或者更新 db 失败，都不会影响数据一致。

能够解决策略 4 中的问题：请求 A 删除缓存，这时请求 B 来查，就会击穿到数据库，B 读取到旧的值后写入缓存，A 正常更新 db, 由于时间差导致数据不一致的情况，描述图如下：

![648e639cac0f17ad3ce162ace865182e.png][]

本策略中步骤 1 为 expire 缓存，不会发生击穿缓存到数据库的情况，数据将直接返回。除非更极端情况，如下图:

expire 时间没有覆盖住更新 db 的耗时，类似策略 1 中极端场景，此处不赘述

![0a6da4e8b1b41c4e194f8309176767ac.png][]

#### **四、总结** ####

对于每种方案策略，各有利弊，但一致性问题始终存在（文章开头排除了原子性和锁），只是发生的几率在一点点慢慢变小了，方案的评估不仅要根据自身系统的业务场景，如读写比、并发量、一致性容忍度，还要考虑系统复杂度，投入产出比等，寻找最合适的方案。

[36a815ad0850b37225239195a3bdfbdd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/ea51553333cc4df3a3567a918a17e858.png
[322e746b5e6c66467e3e62c10f19ec61.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/bf842f9e5d6248018193a6add4e06c16.png
[05c37376b751f8791135923c20262d87.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/45000ffd302a4137988aafdde7e44f3d.png
[72eff49b5df2cf82b5dc4cb8200e35e8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/e6ac2c4f0cad44f1946932c13fe4f5d3.png
[64f8745cab057052f330c3ac5312e4f2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/3058d049dab54c06ac1afd97cf54c412.png
[52d07b699dcbc9e696795ff731ded682.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/ffb08067e19e49f3a828bca4e1c6ebb3.png
[81b17e3be77444a41e7f2de1536b5c01.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/3370361713214d3fbf129f05f2c201cb.png
[648e639cac0f17ad3ce162ace865182e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/220f9da638d040adbb9da5e57f9f9f9b.png
[0a6da4e8b1b41c4e194f8309176767ac.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/fca87d27dbc648d5962a072fb038e79a.png