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

2019-07-29 本文已影响0人小螺丝钉cici

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

二次提交

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 恢复方式
向后恢复补偿所有已完成的事务，如果任一子事务失败
向前恢复：重试失败的事务，假设每个子事务最终都会成功（运用不到，因为一个服务挂掉，再怎么重试，都没有意义）

备注：