面试官，别再问我MySQL和redis数据一致性问题了
缓存与数据库
缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。
例如对于用户的余额信息表 account(uid, money)，业务上的需求是：
- 查询用户的余额，SELECT money FROM account WHERE uid=XXX，占 99% 的请求
- 更改用户余额，UPDATE account SET money=XXX WHERE uid=XXX，占 1% 的请求
由于大部分的请求是查询，我们在缓存中建立 uid 到 money 的键值对（uid -> money），能够极大降低数据库的压力。
读操作流程：
- 读取缓存中是否有相关数据，uid -> money
- 如果缓存中有相关数据 money，则返回【数据命中 hit】
- 如果缓存中没有相关数据 money，则从数据库读取相关数据 *money【数据未命中 miss】，放入缓存中 uid -> money，再返回
缓存的命中率 = 命中缓存请求个数/总缓存访问请求个数 = *hit / (hit + miss)
问题来了：
当余额数据 money 发生变化的时候：
- 是更新缓存中的数据，还是淘汰缓存中的数据呢？
- 是先操纵数据库中的数据再操纵缓存中的数据，还是先操纵缓存中的数据再操纵数据库中的数据呢？
- 缓存与数据库的操作，在架构上是否有优化的空间呢？
是更新缓存中的数据，还是淘汰缓存中的数据呢？
更新缓存：
- 数据不但写入数据库，还会写入缓存
- 优点：缓存不会增加一次 cache miss，命中率高
淘汰缓存：
- 数据只会写入数据库，不会写入缓存，只会把数据淘汰掉
- 优点：简单
- 缺点：增加了一次 cache miss
取决于 更新缓存的复杂度：
例如，上述场景，只是简单的把余额 money 设置成一个值，那么：
- 淘汰缓存的操作为 deleteCache(uid)
- 更新缓存的操作为 setCache(uid, money)
更新缓存的代价很小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率。
如果余额是通过很复杂的数据计算得出来的，例如业务上除了账户表 account，还有商品表 *product，折扣表 discount。
业务场景是用户买了一个商品 product，这个商品的价格是 price，这个商品从属于 *type 类商品，type类商品在做促销活动要打折扣 zhekou，购买了商品过后，这个余额的计算就复杂了，需要：
- 先把商品的品类，价格取出来：SELECT type, price FROM product WHERE pid=XXX
- 再把这个品类的折扣取出来：SELECT zhekou FROM discount WHERE type=XXX
- 再把原有余额从缓存中查询出来 money = getCache(uid)
- 再把新的余额写入到缓存中去 setCache(uid, money - price \ zhekou)*
更新缓存的代价很大，此时我们应该更倾向于淘汰缓存。
先操作数据库 VS 先操作缓存
当写操作发生时，假设 淘汰缓存 作为对缓存通用的处理方式，又面临两种抉择：
- 先写数据库，再淘汰缓存
- 先淘汰缓存，再写数据库
对于一个不能保证事务性的操作，一定涉及 哪个任务先做，哪个任务后做 的问题，解决这个问题的方向是：
如果出现不一致，谁先做对业务的影响较小，就谁先执行。
假设先写数据库，再淘汰缓存：
- 更新数据库操作成功，将编号 001 的账号的余额从 50 元更新为 100 元
- 可是淘汰缓存操作失败，缓存中是旧数据 50 元，从而造成了 数据不一致，用户查询时，在缓存中命中，返回 50 块的错误余额
结论是：应该先淘汰缓存，再写数据库。
这样即使第二步写数据库失败，则只会引发一次 cache miss。
缓存架构优化
传统架构：如下所示。缺点：业务方需要同时关注缓存与 数据库。
传统架构
主流优化方案是 服务化：加入一个服务层，向上游提供数据访问接口，向上游屏蔽底层数据存储的细节，这样业务线不需要关注数据是来自于缓存还是数据库。
