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 支持我们！

微信交流群

关注『微服务实践』公众号并点击 进群 获取社区群二维码。