缓存系统设计有哪些性质

这篇文章主要讲解了“缓存系统设计有哪些性质”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“缓存系统设计有哪些性质”吧！

Previously

缓存系统涉及的问题和知识点是比较多的，我主要分为以下几个方面来跟大家探讨：

• 稳定性

• 正确性

• 可观测性

• 规范落地和工具建设

缓存正确性

数据更新常见做法

首先，我们讲数据一致性的前提是我们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再来请求时缓存里没有，就会查询数据库，并回写缓存再返回结果

• 后续的请求就会直接读取缓存了

另外留一个问题大家可以思考下，对于下图的场景，我们该怎么应对？

感谢各位的阅读，以上就是“缓存系统设计有哪些性质”的内容了，经过本文的学习后，相信大家对缓存系统设计有哪些性质这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！