缓存与数据库的双写一致性

首先我们知道，现在将高速缓存应用于业务当中已经十分常见了，甚至可能跟数据库的频率不相上下。你的用户量如果上去了，直接将一个裸的 MySQL 去扛住所有压力明显是不合理的。
这里的高速缓存，目前业界主流的就是 Redis 了，关于 Redis 相关的文章，之前也有聊过，在此就不赘述，感兴趣的可以看看：
额，不列出来我都没感觉关于 Redis 我居然写了这么多...言归正传。
在我们的业务中，普遍都会需要将一部分常用的热点数据（或者说不经常变但是又比较多的数据）放入 Redis 中缓存起来。下次业务来请求查询时，就可以直接将 Redis 中的数据返回，以此来减少业务系统和数据库的交互。
这样有两个好处，一个是能够降低数据库的压力，另一个自不必说，对相同数据来说能够有效的降低 API 的 RT（Response Time）。
后者其实还好，降低数据库的压力显得尤为重要，因为我们的业务服务虽然能够以较低的成本做到横向扩展，但数据库不能。
这里的不能，其实不是指数据库不能扩展。 MySQL 在主从架构下，通过扩展 Slave 节点的数量可以有效的横向扩展读请求。而 Master 节点由于不是无状态的，所以扩展起来很麻烦。
对，是很麻烦，也不是不能横向扩展。但是在那种架构下，我举个例子，主-主架构下，会带来很多意向不到的数据同步问题，并且对整个的架构引入了新的复杂性。
就像我在之前写的MySQL 主从原理中提到过的一样，双主架构更多的意义在于 HA ，而不是做负载均衡。
所以，相同的数据会同时存在 Redis 和 MySQL 中，如果该数据并不会改变，那就完美的一匹。可现实很骨感，这个数据99.9999%的概率是一定会变的。
为了维护 Redis 和 MySQL 中数据的一致性，双写的问题的就诞生了。
其中最经典的方案就是 Cache Aside Pattern，这套定义了一套缓存和数据库的读写方案，以此来保证缓存和数据库中的数据一致性。
Cache Aside Pattern 具体又分为两种 Case ，分别是读和写。
对于读请求，会先去 Redis 中查询数据，如果命中了就会直接返回数据。而如果没有从缓存中获取到，就会去 DB 中查询，将查询到的数据写回 Redis ，然后返回响应。

本文插图
而更新则相对简单，但是也是最具有争议。当收到写请求时，会先更新 DB 中的数据，成功之后再将缓存中的数据删除。

本文插图
注意这里是删除，而不是更新。因为实际生产中，缓存中存放的可能不仅仅是单一的像 true、false或者1、19这种值。