互联网架构中海量数据一致性

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 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