qidao123.com技术社区-IT企服评测·应用市场

标题: 打破困局：数据库与缓存不一致问题全解析 [打印本页]

作者: 农民 时间: 2025-5-10 13:32
标题: 打破困局：数据库与缓存不一致问题全解析
数据库和缓存不一致性的问题，怎样办理？

答复

扩展

1、为什么要删缓存，而不是更新？

优先选择删除缓存，而不是更新缓存。
更新缓存的动作，相比于直接删除缓存。操作过程比力的复杂，而且，也轻易堕落。
更新缓存的例子：当我们需要通过缓存进行扣减库存的时候。
- 你可能需要从缓存中查出整个订单模型数据，
- 把他进行反序列化之后，再解析出其中的库存字段，
- 把他修改掉，然后再序列化，
- 末了，再更新到缓存中可以看到
缓存删除 带来的一个小问题
缓存删除会带来一次 cache miss。
这种 cache miss 在某种程度上，可能会导致缓存击穿，
通过加锁的方式，比力方便的办理缓存击穿的问题的。

2、先写数据库，照旧先删缓存？

先删缓存，再写数据库
- 长处：先删除缓存乐成了，但是，第二步更新数据库失败了，这种情况是可以接受的。
- 缺点：这种方式，会无形中放大 “读写并发”，导致的数据不一致的问题。
           对于一个读线程来说，虽然，不会写数据库，但是，会更新缓存的。
     数据不一致的问题，示例：
     假如一个读线程，在读缓存的时候没查到值，他就会去数据库中查询。
     假如，在查询到结果之后，更新缓存之前，数据库被更新了。
     但是，这个读线程是完全不知道的。
     那么，就导致终极缓存会被重新用一个“旧值”覆盖掉。
     这样，就导致了缓存和数据库的不一致的现象
先写数据库，再删缓存
- 利益1：缓存删除失败的概率照旧比力低的。
- 利益2：数据库是作为持久层存储的。先更新数据库，就可以包管数据的可靠性和一致性。
- 问题：先写数据库，后删除缓存，假如，第二步失败了。会导致数据库中的数据已经更新，缓存照旧旧数据。终极，导致数据不一致。
延迟双删
- 参考：延迟双删？

3、怎样选择？

业务量不大，并发不高的情况，可以选择**“先更新数据库，后删除缓存”**的方式，因为，这种方案更加简单。
先操作数据库，后操作缓存。是一种比力范例的计划模式一 Cache Aside Pattern
这种模式的主要方案就是，先写数据库，后删缓存。而且，缓存的删除是可以在旁路异步实行的。
这种模式的长处，他可以办理 “写写并发“导致的数据不一致问题，并且，可以大大降低“读写并发”的问题。
所以，这也是Facebook比力推崇的一种模式。
业务量比力大，并发度很高的话，那么发起选择 “先删除缓存，再更数据库”。因为，这种方式在引入延退双删、分布式锁等机制，会使得整个方案会更加趋近于完美，带来的并发问题更少。当然，也会更复杂。

4、方案再优化

Cache Aside Pattern 这种模式中，我们可以异步的在旁路处置惩罚缓存。
实现方式：借助数据库的 bin log 大概基于异步消息订阅的方式。
- 先操作数据库，数据库操作完，发一个异步消息出来。
- 然后，再由一个监听者在接到消息之后，异步的把缓存中的数据删撤除。
- 大概，借助数据库的 binlog，订阅到数据库变更之后，异步的扫除缓存。

5、缓存更新的计划模式

Read/Write Through Pattern
- Read Through 模式
  是由缓存配置一个读模块，它知道怎样将数据库中的数据写入缓存。
  在数据被哀求的时候，假如未命中，则将数据从数据库载入缓存。
- Write Through 模式
  缓存配置一个写模块，它知道怎样将数据写入数据库。
  当应用要写入数据时，缓存会先存储数据，并调用写模块将数据写入数据库
- 这两种模式下，不需要应用本身去操作数据库，缓存本身就把活干完了。
Write Behind Caching Pattern
- 在更新数据的时候，只更新缓存，而不更新数据库。然后，再异步的定时的，把缓存中的数据持久化到数据库中。
- 长处/缺点：读写速率都很快，但是，会造成一定的数据丢失。
- 得当场景：可以用在比如：统计文章的访问量、点赞等场景中。答应数据少量丢失，但是，速率要快。

6、没有银弹

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 qidao123.com技术社区-IT企服评测·应用市场 (https://dis.qidao123.com/)