一文看懂微服务世界性技术难题——分布式事务

腾讯云开发者

墨衍会员 · AI 创作全网分发码龄10年

关注

原创 2024-06-25 08:44:16 1.2k 阅读 AI 写同款· GEO 优化 ›

👉目录

1 问题简述

2 分析探讨

3 事务小结

让我们聊聊微服务的老大难：分布式事务。这是个已经被无数次讨论的问题，网上文章多如牛毛。本文从业务底层视角出发，探讨分布式事务究竟难在何处，以及务实的解决之路走向何方，再加一根牛毛... 不过希望本文是比较不一样的视角，能给到读者不同的启发。

在微服务架构流行的背景下，分布式事务的文章多如牛毛，虽然很多将事务一致性与副本一致性混为一谈，也仍不可否认其中相当一部分文章、开源代码，也还是不错的。

然而当你跃跃欲试，期待将业界所谓成熟方案落地，可能很快就会发现现实的骨感 —— 对于大量互联网业务，尤其是在大并发、大量使用 nosql 数据库的微服务架构下，很难落地。

01

问题简述

分布式事务，即在分布式环境下，对于同一个事务下的几件事情，要么一起完成，要么就和什么都没发生一样。也就是我们一般最关注的，是 ACID 中的 A，因为拆分了服务之后，每一步远程 RPC 都可能故障。

例如张三给李四转账，张三的钱扣了，李四的钱加了，这两件事情，显然就应该一起完成，或者就都没做。

注意这里不要发散到 Paxos、Raft 等一致性协议上去，因为他们的领域本来就不同。

Paxos 针对的是多个节点重复做相同的一件事情，主要处理的是多副本之间的一致性：

节点1完成任务1
节点2完成任务1
节点3完成任务1

分布式事务则显然不同，它针对的是有几个不同的任务，要捆绑一起完成或失败，重点在整体的原子性：

节点1完成任务1
节点1完成任务2
节点1完成任务3

02

分析探讨

2.1 超时的难题

这里开门见山，让我们不妨抛开具体的分析过程，直击问题要害，那就是 —— 超时的处理。

明确的成功 / 失败都好说，但是超时呢，有可能成功了，也有可能没成功。在大量现实场景下，只有明确地知道 A 和 B 的真实执行情况，才能采取对应的后续措施，这点比较显而易见，此处不做展开。

那我们要怎么知道 A 和 B 的真实执行情况呢？“立字据” 成了必然的选择，也就是应该要能对账反查。

2.2 对账反查能力

A 和 B 这两件事，是关联到一个事务的，这就要求，要有一个唯一事务 ID（这个 ID 还可以绑定一些其他附属信息），我们可以通过这个 ID 来做对账。如果能对账，那么幂等也会顺利成章就支持了。

唯一的事务 ID 生成很简单，如何通过这个 ID 来对账才是关键所在。

为了安全可靠，我们必须使用落地的信息来 “立字据”，ID 要体现在落地的数据中，这样我们就可以事后查询相关数据得知真正执行的情况，从而可以继续将事务推进下去。

接下来我们看不同情况下，落地信息具体如何记录。

2.3 通过本地日志落地

采用进程本地打日志的方式落地，可以配合网盘或者可靠日志采集等方式做集中化收集处理，这种做法其实也只能从事务角度记录一些信息，至于业务数据本身是否明确修改 ok，在 DB timeout 时并不得而知，需要通过 WAL 日志冗余多记录一些东西（DB 修改前后的预期值都可以记录），这样无论 DB 操作成功与否，在一定的前提下，也能继续推进处理（例如以锁定用户为前提，可以再将 db 数据查回来做核对，就知道是否操作 ok 了，更多讨论参考本章第 9 小节）。

2.4 SQL 存储的落地反查

SQL 存储通常可以基于 “本地事务” 来做反查，类似 seata 之类的解决方案，建个 undo log 表，操作业务数据库表 sql 的同时，会拦截绑定同库内 undo log 表的 sql 插入，一起作为一个本地事务来提交。也就是业务 sql 与 undo log 表的 sql，能通过本地事务进行关联，保证一起成功和失败，这样通过反查 undo log 表，即可得知超时的 sql 到底是否执行成功了。

开启本地事务
  add 业务sql：具体业务逻辑对应的 sql
  add undolog 表sql：insert 一条 undo log，key 包含事务 ID // 基于该表反查
提交本地事务

2.5 NoSQL 存储的落地反查

NoSQL 存储不一定有本地事务能力，如果支持本地事务的话，那和 sql 差不多，绑定批量操作做事务就好了（redis 有支持，如果对一致性要求不是很苛刻，或许凑合能用）。

如果不支持的话，这里提供两种对账的思路：

通过落地日志的方式，将 ID 和操作结果体现到流水日志中，然后通过准实时的接口支持查日志来判断真正执行的情况。这种做法，侵入了存储访问的 API，写请求都带上 ID，且需要存储服务支持流水查询，自研的 kv 存储可以考虑该方案。
直接将 ID 附着在存储记录里，例如 NoSQL 的 value 里面加一个事务 ID 数组（然后按大小滚动，条数上限够用就行），写操作会留下 ID 的 “痕迹”。这种做法，侵入了业务表结构，表本身要挂这么一个数组。用 proto 描述示例如下：

// 业务表示例
message ServiceTable{
  repeated string txids = 1; // 事务 id 数组，按一定 size 滚存
  int32 field1 = 2;
  int32 field2 = 3;
  int32 field3 = 4;
  int32 field4 = 5;
  // ...
}

上述这两种做法，显然都谈不上优雅，但这样也算是能建立基本的对账能力，尤其值得一提的是方案 2)，理论上适用于所有类型的 kv 存储。

2.6 外部接口

如果分布式事务还关联了外部接口调用，那外部接口的超时，则需要依赖合作方提供对账、幂等能力。

2.7 微服务典型复杂场景

对于典型复杂的微服务场景，这里举例说明：

事务开启
  任务1：改数据 A // sql 存储
  任务2：改数据 B // nosql 存储
  任务3：调用系统内服务接口 C // -- 被调服务可能是类似情况
  任务4：调用外部门服务接口 D
事务结束

假如我们通过一些手段，使得底层事务原子任务终于支持了对账反查能力，采用哪种应用层的事务方案，依然要三思。小规模业务或许本来对吞吐没啥要求，可以积极尝试。但大规模业务，请求量大，数据复杂，事务底层涉及到的底层数据资源一排列组合，情况就非常复杂了，例如：

// A B C D 四种数据
并行事务一：改 A B C
并行事务二：改 B D
并行事务三：改 B A
并行事务四：改 C D

不难想象，这里事务锁怎么加都是个问题，如果一把大锁，吞吐显然受限，如果细粒度锁，那该如何设计对应的粒度？所以对于大规模业务，可能得特事特办，例如仅仅是 cover 一下真的有强烈事务诉求的场景，其他场景下就直接有损处理。对应上述伪码，可能只有事务一继续是事务，其他三个就干脆不作为事务了。还有锁的时效性问题，以及是否存在并发锁，并发锁要不要和事务锁用同一把锁，都要考虑。

2.8 为什么 DB 层能做而业务不好做

前面说了做好分布式事务的一些难处和前置条件，了解 NewSQL 的读者可能会有这样的疑问：TDSQL、TiDB 他们不都已经号称支持了跨库跨表的分布式事务了么，凭什么他们数据库系统能做，怎么我们业务层反而为难了，不是总说数据库才是高精尖么，他们不是应该更难么？是啊，凭什么？

这里的关键在于，数据库系统将跨表事务这个问题收拢到它内部了，关进了它自己的笼子里，然后它自己基于 XA 或其他协议，结合 MVCC 事务锁之类的机制，就可以解决好这个问题。

而在业务层面，潜在的参与方耦合面实在是太广了，无法简单收拢，同一个数据的变更触发源太多了，很难参考 DB 层的解决方案。可能有读者会认为，对于一个具体的数据表，最终将写入操作也只收拢到一个点，确实如此，但是我们关注点并不仅仅在这个点，而是在上层的事务。例如 SvrA 管理了数据表 A，但是 SvrB、SvrC、SvrD 都可以通过 RPC 接口来调用 SvrA 进行数据表 A 的修改，还可以存在级联的情况，例如 SvrE 先调用 RPC 访问 SvrB，然后再由 SvrB 发起 RPC 调用 SvrA 做了数据表 A 的修改。

SvrE ---|
       SvrB----\
       SvrC--- SvrA 数据表A
       SvrD----/

为了努力在业务层面解决事务问题，我们只好又祭出万能大法，加一层或多层抽象，这也正是目前大量上层应用解决方案做的：

增加外在的事务存储（主 key 为事务 ID，记录事务的参与方、进度、子事务等信息）。
要求事务参与方遵循某些约束（如本地事务 / 对账能力），调用特定的一些 API 将事务信息进行上报关联。
引入事务协调者，由它来根据参与方上报的信息做一些事务的驱动逻辑。

具体执行的话，可能还要考虑事务锁的具体实现策略（时效、粒度、与并发锁的关系等），于是问题就会变得更加复杂。

2.9 那牺牲一点可用性呢

前面已经提到，存储层支持对账反查，是分布式事务得以应用的基本前提，那万一存储层就是不好支持对账呢，还能怎么办？

在做分布式系统设计的时候，有个 trick：一致性与可用性之间，有时是可以做置换的，当想要保障一致性的时候，实在没办法，可以想想是否能用一些可用性来置换，反之亦然。

那么我们在产生 timeout 类悬而未决异常的时候，可以牺牲一点可用性来加强事务的一致性保障么，粗想确实是可以的。例如 TCC 方案，try 已经都 ok 了，到了 confirm commit 阶段，有一个参与者其实并没有及时完成 commit 提交，它超时了。通过事务锁，限制事务所涉及用户的数据操作，在 try 阶段加好锁，直到这个悬而未决的事务完整执行完再释放即可。这里对用户加锁，本质上就是牺牲可用性的做法，解锁之前，其他写该用户数据的请求都处理不了。

try 阶段 lock 好
confirm commit... 直至确定 ok 为止
明确完成后才 unlock

假如任由未 confirm 的数据继续提供写接口，则可能导致 confirm 时违反 try ok 的条件（例如字段 A 符合一定条件），那不锁定的话，在重试 confirm 的时候有可能字段 A 都已经被改写得不符合条件了，导致 confirm 实质上失败。

有些特殊场合下，还可以不加锁。例如对于金融转账而言，TCC 还有一种预留冻结金额的做法，就可以不加锁，但这显然和业务强相关，在很多业务场景下并不是一个简单的整数字段操作，常常无法 “预留资源” ，不具普适性。

简而言之，就是要对事务关联的用户，规定一个明确的执行序列（confirm、cancel 都可以），只要事务参与者活着，最终就一定会执行完毕。同时这里要遵循可用性约束，就是该事务关联用户在完成相关执行序列之前，不能放开别的请求修改对应的数据，否则可能会破坏数据一致性，即要锁住用户直至完成事务。

我们再补充考虑下 crash-safe 以及 restart-safe，为了能可靠的按执行序列推进，显然还需要考虑 WAL 日志（如果重启有节点漂移，得用网盘），以及重启后基于 WAL 的逻辑检查和运行，而且这些其实都是很侵入代码的工作。此外如果事务框架还想做一些重试，事务协调者让事务参与者重试 commit，那相关数据的操作逻辑得有幂等能力。还需要指出的是，在分布式环境下，可能出现参与者没收到 try 就收到了 cancel（空回滚），或者收到了 cancel 之后才收到了 try（悬挂）的情况，也都需要处理，也就是无论收到 try 还是 cancel，都得先检查一下相关事务的本地执行情况。

综上来看，这样做确实不一定要求 DB 层支持对账，但必然要考虑锁、WAL、幂等之类的问题，因此想要正确严谨地实现事务也并非易事，换言之，做是能做的，但要考虑细致，然后因为比较侵入，代码复用性可能也不佳。如果不是很重要的业务场合，用上之后性价比不高，且任何机制叠加，还不可避免会带来一些新的依赖和异常，维护成本也会增加。

2.10 特定场景下的简易实现

有些业务场景，对事务隔离性没什么要求，不必加锁，最终一致即可，对时效性也要求不高，同时也能从数据本身的最新值体现出操作是否已成功（例如设置 vip，查回来发现还没设置好就是没成功的），那么此时还是有相对简单的解决方案的。

这类场景下，恰巧是天然的可反查、有幂等，例如对于设置 vip 这步而言：

反查：直接查回来数据看下是否已经 vip 了，就知道执行的结果。
幂等：重新设置很多次 vip 效果也依然一样是个 vip。

具体细节此处就不再更多展开，无非就是结合反查持续重试直至成功即可。除了上面举例的场景，也还会有各种其他的业务场景，都是可能采用折中有损方案应对解决的，但因为太业务相关，不具普适意义，这里不再发散。

03

事务小结

3.1 分布式事务的关键

要有个唯一的事务 ID，否则无法将各个子任务进行关联。
通常要基于事务 ID 实现幂等或对账，否则 timeout 没法正确处理，也无法安全重试。
一致性要求高的场景，会有对资源做锁定或预留的做法，最终一致性要求的场景，则只要最终符合预期即可。基于对资源要求的不同，会有一些常见的解决方案，例如多阶段协商提交、TCC、事务消息等。

现有的各种框架级别的解决方案，一般也就是：