分布式缓存———数据一致性问题

分布式基础理论

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理论，当数据库数据发生数据变更的时候，读取缓存。中间态的数据会返回给业务，所以我们在做分布式与数据库一致性的时候。往往是要减少中间软状态， 通过先更新数据库删除缓存或者先更新数据库后更新缓存 加重试的方案。及时让数据达到最终一致性的状态

缓存与数据库一致性方案

引用干货 | 携程最终一致和强一致性缓存实践_架构_携程技术_InfoQ精选文章

https://juejin.cn/post/6844903941646319623