1.数据不一致性产生原因
2.基于分布式事务彻底解决数据库数据一致性 (XA/2PC/BASE/TCC/Saga/MQ/同步场景/异步 场景等实践)
3.分布式缓存和数据库数据一致性实践(是否高可用 /跨机房等架构实践和背后哲学思考)
原作者：孙玄
1.数据不一致性产生原因
1.1数据一致性的定义：
任何人，任何时间，任何地点，任何接入方式，任何服务，数据都是一致的
1.2数据不一致性产生的原因
a.数据分散在多处 「多个DB，DB和缓存」
b.二手交易平台案例「用户，商品，交易等功能」
image.png
2.基于分布式事务彻底解决数据库数据一致性 (XA/2PC/BASE/TCC/Saga/MQ/同步场景/异步 场景等实践)
案例：以电商平台购买商品 下单->减库存->支付
image.png
- 一般采用的分布式事务场景，有什么问题？
电商下单场景：下单->发送消息到MQ
一致性保证：本地事务（下单操作，发送MQ消息操作，放进一个本地事务）
这种做法无法保证一致性。
2.1分布式事务分类：
a.刚性分布式事务（强一致性，XA模型）
b.柔性分布式事务（最终一致性，CAP／BASE理论）
2.1.1刚性分布式事务
a.满足传统事务特性
(ACID (Atomicity-原子性、Consistency-一致性、Isolation-隔离性、Durability-持久性)
b.XA模型
(1).XA 是 X (Dpen CAE Specification (Distributed Transaction Processing）模型中定义，XA 规范由 AP, RM, TM 组成
(2)其中应用程序（Application Program，简称 AP): AP 定义事务边界（定义事务开始和结東）并访问事务边界内的资源
(3)资源管理器 RM（Resource Manager，简称 RM): 管理计算机共享的资源，资源即数据库等
(4)事务管理器（Transaction Manager，简称 TM）：负责管理全局事务，分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等
image.png
image.png
二次提交
2.1.2 柔性分布式事务
CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。
(1)CAP 分布式环境下P一定需要，CA权衡折中
(2)BASE理论 基本可用／柔性状态／最终 一致性
(3)架构思考
柔性事务是对XA协议的妥协，它通过降低强一致性要求，从而降低数据化库资源锁定时间，提升可用性
(4)典型架构实现
TCC模型／Saga模型
- TCC模型
a.Try-confirm-cancel
b.TC 模型完全交由业务实现，每个子业务都需要实现 Ty- Confirm- Cancel 接口，对业务侵入大
资源锁定交由业务方尝试执行业务，完成所有业务检查，预留必要的业务资源
c.o Confirm真正执行业务，不再做业务检查 o d.Cancel释放 Try 阶段预留的业务资源
案例:
汇款服务、收款服务
A 用户向 B 用户汇款 500 元
image.png
- saga 模型
a.起源于 1987 年 Hector& Kenneth 发表的论文 Sagas
b.Saga 模型把一个分布式事务拆分为多个本地事务，每个本地事务都有相应的执行模块和补偿模块（对应 TC 中的 Confirm 和Cancel)
c.当 Saga 事务中任意一个本地事务出错时，可以通过调用相关的补偿方法恢复之前的事务，达到事务最终一致性当每个 Saga 子事务 T1, T2, Tn 都有对应的补偿定义 C1, C2., Cn-1, 那么 Saga 系统可以保证: - 子事务序列 T1, T2. …, Tn 得以完成（最佳情况
- 或者序列 T1. T2,“T, C-1. …, C2. C1.0≤j <n，得以完成
c.Saga 隔离性 业务层控制并发 - 在应用层加锁
- 应用层预先冻结资源等
d.Saga 恢复方式 - 向后恢复补偿所有已完成的事务，如果任一子事务失败
- 向前恢复：重试失败的事务，假设每个子事务最终都会成功（运用不到，因为一个服务挂掉，再怎么重试，都没有意义）
备注：
- saga模型是将一个长事务变成多个短事务。
如果每个事务都成功，结果一致性。
如果有其中一个事物失败，那么就沿着逆反的方向，一步一步去补偿 - 补偿方法只到Cn-1 ，而不是Cn。
串形事务执行的时候，如果Tn执行失败，就会自动进行补偿。所以，不需要再定义Cn的补偿方法
image.png
2.1.3 如何实战柔性分布式事务
通用处理思路：
本地事务-》短事务
分布式事务-》长事务
转变成多个短事务
业务场景
异步场景：基于 MQ 消息驱动分布事务
同步场景：基于异步补偿分布
案例：异步场景-商品交易 下单-支付
image.png
image.png
image.png
方案一：业务方提供本地操作成功回查功能
- 业务方提供本地操作成功回查功能
- 业务方接入步骤
image.png
优点：通用
缺点：
业务万需提供回查接口，対业务侵入大
发送消息非幂等
消费端需要处理幂等
方案二：本地事务消息表
image.png
image.png
实际异步场景使用较多的是方案二：本地事务消息表
案例：同步场景分布式事务设计
同步场景-首页推荐商品列表／商品信息／用户信息／社交信息
购买商品：下单-> A ； 减库存-> B ；支付-> C
image.png
分布式缓存和数据库数据一致性实践
缓存作用：1.降低请求的响应时间，提升用户体验：2.减少对固化存储的读压力
缓存适合场景：
- 静态资源的缓存
- 较少更改资源的缓存
- 读多写少场景：互联网／读 10 写 1
缓存不适合场景：频繁更新 ／ 读少写多
image.png
image.png
image.png
网友评论