分布式事务

作者: rabbittttt | 来源:发表于2019-03-11 23:02 被阅读0次

1 分布式事务缘起
一切开始于单机时代，人们面临着两个困境：单机服务器性能瓶颈 & 单点故障服务不可用／数据丢失。
因此，人们开始对服务器进行扩展，加入更多的机器分担性能问题，以及解决单点故障，通常使用两种手段来扩展数据服务：

2 ACID -> CAP -> BASE
ans：（1）ACID 即事务的特征，此处不再详述
（2）C（Consistency 一致性）A（Availability 可能性）P（Partition tolerance 分区容错性），对于一个分布式系统，三者是无法全部满足的，只能舍一取二。

如果放弃C（这里指强一致性），那么系统无法保证数据实时一致，虽然在时间窗口之后数据将最终到达一致，但时间窗口内数据是不一致的。
如果放弃A（可用性），那么当遇到故障时，服务的质量会下降甚至无法提供正常服务
如果放弃P（容错），那么就是放弃了分布式，放弃了系统扩展性。
一般来说P是绝不能放弃的，因此一般在C or A 中权衡（看场景）。
（3）BASE 是基于CAP演化而来，核心理念是即使无法做到强一致性，每个应用也可以根据自身特点，采用适当的方式来使系统到达最终一致性。
BA（Basically Available 基本可用），出现故障时，允许损失部分可用性，但不等于系统完全不可用。例如：出现故障时，响应时间增加；或流量高峰时屏蔽部分功能以保证系统稳定（服务降级）
S （Soft state 软状态），允许系统在不同结点的数据副本之间进行数据同步的过程存在时延。
E（Eventually consistent 最终一致性），强调系统保证最终数据达到一致，不需要保证实时的强一致性。
参考：https://segmentfault.com/a/1190000004468442

3 分布式事务实现
3.1 2pc & 3pc
ans：（1）2pc，Tow-Phase Commit 两阶段提交

2pc

2pc 的问题在于，在第二阶段，如果某个参与者收不到协调器的commit/fallback指令，那么它将一直处于“状态未知”阶段，完全不知道该怎么办。要么一直等待协调者，要么重发第一阶段的反馈，资源不能得到释放。
（2）3pc，Three-Phase Commit 三阶段提交

3pc
对于2pc，协调者对事务完成至关重要，一旦协调者异常那么可能block整个事务。因此衍生出了 3pc。3pc的关键点在于：

canCommit 阶段不会锁定资源，基于一个认知：如果第一阶段所有参与者ok，那么第二阶段有很大概率认为能够提交成功，这样第一阶段的询问能够降低第二阶段可能回滚的概率。
preCommit阶段，即使协调者故障，参与者也不会等在原地，超时后将自动commit，避免了 2pc 的问题。但这也存在一个隐患：preCommit 阶段一旦不能正常通信，而参与者的默认操作是commit，如果数据需要rollback 那么会出现数据不一致的情况。
2pc 3pc归根到底是选择系统可用性还是选择系统一致性（CAP理论中的抉择问题）
2pc 一致性好、可用性较低，3pc 一致性较低、可用性高
参考：https://segmentfault.com/a/1190000004474543
https://coolshell.cn/articles/10910.html
http://www.cnblogs.com/hubaoxi/p/6867203.html

3.2 TCC
ans： TCC（Try-Confirm-Cancel）又称补偿事务。其核心思想是："针对每个操作都要注册一个与其对应的确认和补偿（撤销操作）"。它分为三个操作：

Try阶段：主要是对业务系统做检测及资源预留
Confirm阶段：确认执行业务操作
Cancel阶段：取消执行业务操作
TCC 本质是一个应用层面的2PC，优点在于可以自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐成为可能；缺点在于，对应用入侵性非常强，业务逻辑的每个分枝都需要实现 try/confirm/cancel 三个操作，confirm/cancel 必须实现幂等。
TCC
参考：https://www.cnblogs.com/wudimanong/p/10340948.html
https://juejin.im/post/5bf201f7f265da610f63528a

3.3 本地消息表（eBay 事件队列方案——保证最终一致性—异步确保）
ans：核心思想是将分布式事务拆分成本地事务进行处理。

上游服务在自己的数据库中保存一个消息发送记录，然后将消息投递出，这两步可以用本地事务处理。
下游服务接收消息后进行处理，之后通知上游成功 or 失败
如果这之间出现故障导致下游未收到消息／超时，上游可以定时扫描消息发送记录，将未完成的消息重发一遍
优点：一种非常经典的实现，避免了分布式事务，实现了最终一致性。
缺点：消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理，但可以抽象出一个消息发送服务来处理
参考：https://blog.csdn.net/mine_song/article/details/64118963
https://blog.csdn.net/tangdong3415/article/details/59117947
https://cloud.tencent.com/developer/article/1117449
https://juejin.im/post/5bf2c6b6e51d456693549af4 前半部分