共计 1498 个字符，预计需要花费 4 分钟才能阅读完成。
Previously
缓存零碎波及的问题和知识点是比拟多的，我次要分为以下几个方面来跟大家探讨：
- 稳定性
- 正确性
- 可观测性
- 标准落地和工具建设
上篇 咱们剖析了缓存零碎的稳定性，介绍了 go-zero 是怎么解决缓存穿透、缓存击穿、缓存雪崩问题的。比拟浅显易懂，且具备比拟强的实战意义，举荐一读。
本文作为系列文章第二篇，次要跟大家探讨『缓存数据一致性』
缓存正确性
上篇文章提到，咱们引入缓存的初衷是为了减小 DB 压力，减少零碎稳定性，所以咱们一开始关注的是缓存零碎的稳定性。当稳定性解决之后，个别咱们就会面临数据正确性问题，可能会常常遇到『明明数据更新了，为啥还是显示老的呢？』这类问题。这就是咱们常说的『缓存数据一致性』问题了，接下来咱们认真下剖析其产生的起因及应答办法。
数据更新常见做法
首先，咱们讲数据一致性的前提是咱们 DB 的更新和缓存的删除不会当成一个原子操作来对待，因为在高并发的场景下，咱们不可能引入一个分布式锁来把这两者绑定为一个原子操作，如果绑定的话就会很大水平上影响并发性能，而且减少零碎复杂度，所以咱们只会谋求数据的最终一致性，且本文只针对非谋求强一致性要求的高并发场景，金融领取等同学自行判断。
常见数据更新形式有两大类，其余根本都是这两类的变种：
- 先删缓存，再更新数据库
这种做法是遇到数据更新，咱们先去删除缓存，而后再去更新 DB，如左图。让咱们来看一下整个操作的流程：
- A 申请须要更新数据，先删除对应的缓存，还未更新 DB
- B 申请来读取数据
- B 申请看到缓存里没有，就去读取 DB 并将旧数据写入缓存（脏数据）
- A 申请更新 DB
能够看到 B 申请将脏数据写入了缓存，如果这是一个读多写少的数据，可能脏数据会存在比拟长的工夫（要么有后续更新，要么期待缓存过期），这是业务上不能承受的。
- 先更新数据库，再删除缓存
上图的右侧局部能够看到在 A 更新 DB 和删除缓存之间 B 申请会读取到老数据，因为此时 A 操作还没有实现，并且这种读到老数据的工夫是十分短的，能够满足数据最终一致性要求。
上图能够看到咱们用的是删除缓存，而不是更新缓存，起因如下图：
上图我用操作代替了删除或更新，当咱们做删除操作时，A 先删还是 B 先删没有关系，因为后续读取申请都会从 DB 加载出最新数据；然而当咱们对缓存做的是更新操作时，就会对 A 先更新缓存还是 B 先更新缓存敏感了，如果 A 后更新，那么缓存里就又存在脏数据了，所以 go-zero 只应用删除缓存的形式。
咱们来一起看看残缺的申请解决流程：
留神：不同色彩代表不同申请。
- 申请 1 更新 DB
- 申请 2 查问同一个数据，返回了老的数据，这个短时间内返回旧数据是能够承受的，满足最终一致性
- 申请 1 删除缓存
- 申请 3 再来申请时缓存里没有，就会查询数据库，并回写缓存再返回后果
- 后续的申请就会间接读取缓存了
另外留一个问题大家能够思考下，对于下图的场景，咱们该怎么应答？
如果你有好的解决办法或者想晓得怎么解决，欢送 go-zero 社区微信群内交换，授人以鱼不如授人以渔，求解的过程必将让你播种更多~~
未完待续
本文跟大家一起探讨了缓存数据一致性问题，下一篇我来跟大家一起探讨缓存零碎的监控以及如何让缓存代码更标准、更少 bug。
所有这些问题的解决办法都已蕴含在 go-zero 微服务框架里，如果你想要更好的理解 go-zero 我的项目，欢送返回官方网站上学习具体的示例。
视频回放地址
ArchSummit 架构师峰会 - 海量并发下的缓存架构设计
我的项目地址
https://github.com/tal-tech/go-zero
欢送应用 go-zero 并 star 反对咱们！
微信交换群
关注『微服务实际 』公众号并点击 进群 获取社区群二维码。
go-zero 系列文章见『微服务实际』公众号
