数据缓存一致性方案
内容要点
- 背景介绍
- 缓存系统目标
- 缓存写一致性方案分析
- 缓存读一致性方案分析
- 总结
背景介绍
背景介绍：1.使用Redis缓存数据，MySQL为DB持久储存层。在DB中有一些关键性表的读请求量大，而更新不是很频繁(但是更新的内容都是关键性的)
2.MySQL底层暂时没有能力修改，所以不讨论在MSQYL层监听数据改动时触发缓存的同步更新;另外一个原因是，公司还有其它系统使用ES来持久层
3.
缓存系统目标
对于使用端来说，必须保证从缓存中读取到的数据与DB层中的数据是一样的（特别是核心数据）。
针对上述场景，必须要保证缓存数据的强一致性才行
那么总体上讲有两种实现方案可选择，
第一种方案是在数据修改时候进行与缓存数据的同步即是缓存写一致性方案；
第二方案是在读取的时候与DB层的数据进行同步即是缓存读一致性方案。
缓存写一致性方案
在修改数据时与缓存进行同步的基本方案大致为，如下图：
上述流程的梳理过程为（AB的先后顺序并不是只能A在前B在后，这里只一个例子）：
A.修改业务数据的操作
B.再修改缓存的数据
C.其它操作
先讨论一下单线程情况下会出现哪些问题，能不能保证数据库中与缓存中的数据是一致的？
1.数据库更新成功并且事务提交成功，缓存更新成功,结果是一致性的
2.数据库更新失败则throw excetion,结果是一致性的
3.数据库更新成功，缓存更新失败(如何检测缓存失败)也可throw exception,结果是一致性的
4.数据库更新成功，缓存更新成功，但是数据库事务提交失败，结果是不一致的
多线程并发的情况下问题就更复杂了，缓存数据有可能是不一致或是脏数据：
造成一致性难以难以维护的原因有：数据库有一个事务，缓存Redis没有真正意义上的事务操作
缓存读一致性方案
既然在数据修改时很难保持数据的一致性，那就换个思路：在缓存数据读取的时候看看是否有可行的方案？
步骤一:在业务处理层
A.标识缓存key失效，并累加次数
B.业务数据保存
说明：如果失效标识动作失败，则可直接throw excetion
如果失效标识动作成功，但数据更新失败可直接throw exception（这种情况下会浪费一次数据库的查询，详情参阅缓存数据读取过程）
如果失效标识动作成功，数据更新成功，但数据库事务提交失败则业务数据会回滚。
步骤二:缓存数据读取
说明：
A.先查询缓存对应的key是否存在失效的标识，如果不存在:
则看对应的缓存数据是否存在如果存在则直接返回数据，
如果不存在则查询数据后将数据同步到缓存，再返回数据
B.先查询缓存对应的key是否存在失效的标识，如果存在：
缓存数据存在: 查询数据库听数据与缓存数据比较，不同则将失效次数减一
缓存数据不存在:查询数据库数据后更新到缓存后返回
与失效缓存最后的操作时间比较，如果当前时间超过一定时间(比如3s)则取数据库
中最新的数据覆盖缓存数据同时将缓存失效标识清除
C.
总结:
两种方案的利弊：
写一致性：很难保证数据的强一致性，特别是在高并发请求下
读一致性：可以做到数据的强一致性要求，但是会牺牲缓存的命中率(有一小部分的请求会发到DB层，)。总体上来说就是在数据变化之后，在读缓存数据时在做数据一致性的处理