分布式交易的一致性机制

分布式交易随着微服务（Micro Service）的兴起再次收到重视。

传统软件场景下，业务需求相对稳定，业务规模增长平缓，可以进行有效预判。此时，宏服务（Macro Service）架构是最合适的选择。该架构下很容易实现数据的 ACID 一致性，以及对失效交易进行回滚（roll back）。

但是当业务需求变化剧烈，规模增长很难预判（典型如互联网场景）时，传统软件架构很难进行动态调整和快速演进。此时，采用多种服务单元合作的微服务架构就成为很自然的选择。

分散架构随之带来分布式交易的问题。首先，一笔交易可能包括多个请求，涉及多个数据源，需要多个服务单元进行处理。交易路径长，故障概率增大。一旦某个单元处理失效，将可能导致交易失效。同时，交易涉及多个状态可能是分布式存放，难以回滚。这些都让分布式交易成为一个很大的挑战。

目前，保障分布式交易一致性主要包括两种基本思路：两阶段提交和 Sagas。

Two Phase Commit（2PC）

两阶段提交是最朴素的思路。第一阶段准备过程试图让所有涉及到的服务单元预留状态和资源，类似 ATM 网络的设计思路。第二阶段提交建立在第一阶段的可靠性基础之上。

这种思路实现最为简单，而且保障较强的一致性。大部分数据库系统都是基于 2PC 来实现。

主要问题是：第二阶段缺乏可靠性保障，而且在交易处理复杂、时间较长时，锁定资源会造成很高的浪费。

2PC 的变体还包括 XA 和 Try-Confirm/Cancel（TCC） 等。

SAGAS

Saga 也是很古老的思路，于1987年提出，目的是解决 2PC 锁资源的问题。

既然不锁资源，那么就只能是将一个长的交易请求分成多个短的子交易，类似分组转发网络的设计思路。如果某个子交易失败，则需要撤销所有关联子交易，可以通过再发出补偿交易来实现。

实现上可以通过多个子交易之间的事件通知，也可以通过集中机制来调度。

这种方法能解决锁资源的问题，达到高性能，但是过程复杂，回滚代价高，而且如果补偿机制设计不好容易出现互锁。

===== 关于 TechFirst 公众号 =====

专注金融科技、人工智能、数据科学相关领域的热门技术与前瞻方向。欢迎投稿！

如果你喜欢公众号内容，欢迎鼓励一杯 coffee~