分布式缓存———数据一致性问题
分布式基础理论
CAP理论 与 BASE理论-CSDN博客
分布式系统会的三座大山：NPC。
- N：Network Delay，网络延迟
- P：Process Pause，进程暂停（GC）
- C：Clock Drift，时钟漂移
在当前主流k8s服务部署的一个service通常存在多个pod。多个pod对数据进行读写操作经常会出现数据不一致性的问题。不一致的问题主要是在数据库发生数据变更后，多个pod高并行读取数据受到网络，gc等问题可能导致缓存里的数据是旧值
影响分布式缓存数据一致性大致有以下几类问题：
- 获取数据时候网络延迟N
- 各个pod内部gc的触发不一致C
- 数据库主从，读写分离的问题
多个pod对同一份数据并行操作，受到N,C的影响。导致对同一个key缓存的操作，缓存更新后还是旧版本数据，从而对我们业务造成影响。
为什么使用缓存
使用缓存我们一般为了提高我们的系统性能，减少数据库的压力。如果我们追求强一致性，强一致性方案往往会严重的影响性能，常见2pc，3pc方案。
强一致性：读 DB 优先，主要依赖数据库的强一致性，缓存仅作为“DB 降压”的辅助手段。 看到有一种方案在cache side业务模型中，通过setnx来实现分布式缓存互斥，缓存过期时间设置非常短达到降压效果。查db的时候,db性能受到影响，我们通过主从读写分离，分库分表来提高查询性能。 有时候根据业务比如基金业务，基金最新数据我们可以通过分表，表里通过基金唯一索引，数据一直更新的操作，这样这张表一直是小表的查询。
最终一致性：基于base理论，当数据库数据发生数据变更的时候，读取缓存。中间态的数据会返回给业务，所以我们在做分布式与数据库一致性的时候。往往是要减少中间软状态， 通过先更新数据库删除缓存或者先更新数据库后更新缓存 加重试的方案。及时让数据达到最终一致性的状态
缓存与数据库一致性方案
先更新数据库，再更新缓存
线程A（或者机器A，道理是一样的）和线程B需要更新同一个数据，A先于B但时间间隔很短，那么就有可能会出现：
- 线程A更新了数据库
- 线程B更新了数据库
- 线程B更新了缓存
- 线程A更新了缓存
在并发场景下无法保证缓存和数据一致性，解决方案是加「分布锁」，但这种方案存在「缓存资源浪费」和「机器性能浪费」的情况
解决锁粒度的问题，在缓存中我们缓存数据的时候，在表记录数据的时候可以维护一个乐观锁或者RowVesion在更新缓存之前我们可以与缓存时间的RowVesion进行对比如果数据的RowVesion一致或者小于当前缓存RowVesion则放弃修改，否则进行加分布式锁进行数据的更新。
先更新数据库，再删除缓存
请求A是查询请求，请求B是更新请求，那么可能会出现下述情形：
- 先前缓存刚好失效
- 请求A查数据库，得到旧值
- 请求B更新数据库
- 请求B删除缓存
- 请求A将旧值写入缓存
为了保证两步都成功执行，需配合「消息队列」或「订阅变更日志」的方案来做，本质是通过「重试」的方式保证数据最终一致
「读写分离 + 主从库延迟」也会导致缓存和数据库不一致，缓解此问题的方案是「延迟双删」，凭借经验发送「延迟消息」到队列中，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率
多个中间件搭配重试
xxl-job定时任务扫描，业务系统 MQ、binlog 变更 MQ，相互之间作为互补来保证数据不会漏更新。
1，通过canal订阅bin log 解耦系统与中间件的关系。通过canal发起消息来对缓存进行重试。或者直接引入消息对决进行异步重试。
2，引入定时任务扫描，如果是多级缓存，还存在本地cache这个时候通过xxl-job分片广播机制，mq的发布订阅机制搭配，使得缓存及时更新。不会出现漏更新。
3，对存在主从读写分离，我们可以通过延迟事务消息进行数据更新。
引用干货 | 携程最终一致和强一致性缓存实践_架构_携程技术_InfoQ精选文章
https://juejin.cn/post/6844903941646319623