缓存系统设计有哪些性质
这篇文章主要讲解了"缓存系统设计有哪些性质"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"缓存系统设计有哪些性质"吧！
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再来请求时缓存里没有，就会查询数据库，并回写缓存再返回结果
后续的请求就会直接读取缓存了
另外留一个问题大家可以思考下，对于下图的场景，我们该怎么应对？
感谢各位的阅读，以上就是"缓存系统设计有哪些性质"的内容了，经过本文的学习后，相信大家对缓存系统设计有哪些性质这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！
