声明：本文仅限于简书发布，其他第三方网站均为盗版，原文地址： 简单看看缓存一致性的几种做法
缓存是个好东西，一个好的缓存算法[4]可以让我们系统的吞吐能力轻松上升一个到两个数量级。当只有唯一的操作缓存的接口时，一切都很简单；但是，一旦有两个或以上的操作接口时，事情就会变得复杂，其核心的问题就是缓存会被失效，这个时候该怎么处理是个值得探究的问题，而我尝试以我的了解，以 Python 代码为示例，做一下小结。
这是一张展示现代计算机各个不同存储模块的性能对比图，摘自：《深入理解计算机系统》
缓存会失效，大多数情况是因为数据被修改了，还有少数情况是被删除了，所以，我们先关注一下修改的问题。对于修改被缓存数据的策略比较常见的有三种：
- 直写：write-through
- 绕写：write-around
- 回写：write-back
虽然缓存不是一个依赖于语言的东西，但是为了更好得解释以及让我的逻辑更清晰，这里我就使用简单的Python 代码作为示例，希望能够以更容易理解的方式，来模拟不同的这些缓存策略，从而阐述我的理解。
缓存是存储数据的硬件或软件组件，因此可以更快地响应对数据的请求。当然，这些数据肯定要存储在一个自身响应速度快于实际存储的地方（速度对比见上图）。例如，如果您在内存中存储值，则访问数据通常会比访问数据库更快，因为那可是从磁盘读取数据啊。
下面，我要开始我的表演了，就写两个 Python代码 来表示后台存储和缓存先吧：
这里有两个类
- BackingStore：用来表示我们直接从数据库／磁盘中读取数据，也就是比较慢的数据操作
- Cache：表示从缓存中读取数据，也就是很快得数据操作
下面就以这个为框架，一一得介绍我的理解。
直写：write-through
直写的意思就是在数据更新时，同时写入缓存Cache和后端存储。我们用代码来描述一下就是：
这里的可以看到 Line 12，直写操作表示 cache 和 真实数据存储都要同时更新才能成功，这种方法很不错，你更新成功之后，可以保证缓存和真实的数据保持一致，但是，问题也很明显，第一个就是，我们更新的速度会很慢，还有万一更新过程中出错了呢？具体对比我们后续说，下面再看看其他的。
回写：write-back
这种方式就简单多了，具体操作就是只更新缓存，只有当缓存被替换时才进行持久化，代码示例是这样的：
这种方式我们很明显就可以看出来，速度很快，因为根本不涉及到后端的数据存储操作，但是，缺点也很明显啊，我们得关注缓存是不是被替换了，而且还有万一缓存就崩了呢？
绕写：write-around
既然只写缓存风险那么大，那我就直接写后端数据，这样让缓存自动失效之后，再刷新一遍，代码这么看：
这种方式的话优点是可以保证最终的持久数据是正确的，但是，因为我们没有让缓存失效，所以只能等缓存主动失效之后再读取持久数据，同时，更新速度也不快。
对比
基本方式我们上面都介绍过了，但是，只是简单得说说各种方式的优缺点，并没有揉碎了好好说，所以，下面就以一张 Excel 表进行介绍，看看具体的对比：
这里可以看出，各种套路都有自己的优缺点，我们可以根据自己项目的需要进行选择，但是，通常来说，我们引入缓存是因为读多写少，所以可能绕写（Write-Around）用的更多，而且常常配合删除缓存的方法，从而让缓存更新。但是，我们需要清晰得知道删除缓存会带来什么问题，我们是否已经注意到这个问题并且避免了或者不在乎这些问题，具体的讨论可以参考[8]。
本文的代码都托管在 Github：Git Code
