漫谈分布式系统（十三）：再探分布式事务

这是《漫谈分布式系统》系列的第 13 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。

从 ACID 到 BASE

在业务很简单，数据量不大的时候，传统单机关系数据库就够用了。在各个关系数据库里，很早就实现了单机版的事务，并总结成了 ACID 四个特性。

• Atomity，原子性，事务内的所有操作要么全部执行，要么全部不执行。

• Consistency，一致性，事务执行完后，数据库仍然保持合法的状态，如不违反主外键约束等。

• Isolation，隔离性，事务之间互相隔离，并发执行时也不受影响。

• Durability，持久性，事务提交后，涉及的变化都会被持久化下来，不会因系统故障而丢失。

另一个关联很大，但容易混淆的概念，是前面文章讲过的的 CAP。

• Consistency，一致性，不同时刻的不同请求都能返回同样的数据。

• Availability，可用性，每个外部请求都能得到系统的有效响应。

• Partition tolerance，分区容忍性，在出现网络分区时，系统仍然能正常运转。

可以看到，ACID 和 CAP 里的 C 有着完全不一样的含义。前者强调数据库状态始终合法有效，后者强调不同副本上的数据对外而言始终一样。

以 MySQL 为典型的单机关系型数据库能很好的支持 ACID，但是，当数据量和请求并发膨胀到一定程度后，必然会横向扩展为分布式数据库。

典型的实现是在单机数据库的基础上，做多库多表。无论是纵向的对同一类数据的切分，比如把用户表切分后放到 100 个数据库实例；还是横向的对不同类型的数据做切分，比如把用户表和商品表分别放到不同的数据库实例，都是难免的。

数据库变成分布式之后，我们自然能像前面文章介绍的那样， 在单机事务的基础上，通过 2PC 的方式实现分布式事务。

而出于高可用的需要，还可以采用 binlog 等方式把数据复制到 slave 机器上，这个过程也可以通过 2PC 实现。

但是， 任何分布式系统都逃不过 CAP 的诅咒。

前面文章已经详细说明过， 2PC 模式的分布式事务，多轮多节点的协商导致性能不佳，并且无法提供分区容忍性。

虽然 ACID 中的 C 和 CAP 中的 C 含义并不一样，但引申到分布式语境下，ACID 确实也隐含了强一致性保证。而基于 2PC 的分布式事务则在分布式的场景下延续了对强一致性的追求，可以称之为 ACID on 2PC 。哪怕我们继续优化，比如 ACID on 3PC ，也没法从根本上解决问题。

同时，上篇文章说过， 在大数据量和高并发的场景下，有时候，可用性和性能（也可以看作可用性的体现）的重要性并不比一致性弱 。一个动不动不响应或者响应非常慢的系统，数据再一致，也很难大规模应用起来。

一方面，一致性难以完全保证，另一方面，可用性和性能又不能不管，那对分布式事务而言，到底有没有更好的出路呢？

答案是肯定的。并且已经有人将这个思路总结为 BASE 理论：

• BA，Basically Available，基本可用，不追求完整的可用性。部分可用也好过完全不可用。

• Soft state，软状态，不追求状态机那样机械的状态转换，允许出现中间状态。所谓「柔性事务」也是这个意思。

• Eventually consistency，最终一致，不追求无时无刻的强一致。

简单讲，就是 牺牲一部分一致性，来换取可用性 。非常重要也非常典型的 trade-off。

在化学术语中，ACID 是酸的意思，而 BASE 则是碱的意思。从名字上也能看出二者的关系。

基于 Dynamo 的分布式事务

对了啊！上篇文章不是刚介绍过 Dynamo 吗，现成的因果（弱）一致性分布式数据库，那干嘛不直接在 Dynamo 的基础上做事务？！

在客户端实现事务

Amazon 官方曾经提供过一个叫 dynamodb-transactions 的库，来帮助应用在客户端实现分布式事务。

大致来说，是一个多步提交（multi-phase commit protocol）的实现：

• create，创建一个主键唯一的 TX record，保存为 Dynamo 对象。

• add，把事务相关的对象添加到 TX 对象的对象列表里。

• lock，逐个把相关对象的 lock 设置为本 TX id。

• save，保存相关对象的副本，以备回滚。

• verify，重读 TX record，确保状态仍是 pending，以防止和其他事务产生竞争。

• apply，执行事务对应的操作。修改操作会直接改动原对象，删除操作这时不会执行。

• commit，TX record 状态从 pending 改为 commited。

• complete，释放事务相关对象的锁，并删除 save 阶段保存的副本。

• clean，TX record 状态更新为 complete。

• delete，删除 TX record。

看起来列了很多步，有点吓人，实际上只是操作细节而已，和 2PC 的 Prepare-Commit 差不多。

上面是没有出现冲突时的正常执行流程。一旦出现冲突，则会进入另外的处理流程：

• decide，从对象锁拿到占用它的 TX id，判断该 TX 状态，如果是 pending，说明没开始，则改成 roll-back（所以上面正常流程才有 verify 这步）。

• complete，如果该事务状态是 committed，则继续执行正常的提交流程；如果是 roll-back，则执行回滚流程。

• clean，同上的 clean 操作。

可以看到，事务之间是可以互相帮忙推进流程的，这个比较激进的机制当然有利于推动事务尽快完成，但也加剧了竞争。频繁的互相回滚是可以预见的局面。所以可以考虑在 decide 步骤前加入等待等办法来缓解。

除了事务之间的竞争，DynamoDB 还支持多个 coordinator 处理同一个事务，不过解决竞争的思路类似，就不再赘述了。

需要注意的是，apply 阶段的修改操作会直接更新对象，即使事务没提交，这个修改也是可见的。当然，可以通过加读锁来避免。

在服务端实现事务

客户端自己实现总是不方便且容易出错，于是在 2018 年，DynamoDB 终于在服务端集成了事务功能。

// 以下省略 checkCustomerValid、markItemSold 和 createOrder 的定义代码

Collection<TransactWriteItem> actions = Arrays.asList(

new TransactWriteItem().withConditionCheck(checkCustomerValid),

new TransactWriteItem().withUpdate(markItemSold),

new TransactWriteItem().withPut(createOrder));

TransactWriteItemsRequest placeOrderTransaction = new TransactWriteItemsRequest()

.withTransactItems(actions)

.withReturnConsumedCapacity(ReturnConsumedCapacity.TOTAL);

// Execute the transaction and process the result.

try {

client.transactWriteItems(placeOrderTransaction);

System.out.println("Transaction Successful");

} catch (ResourceNotFoundException rnf) {

System.err.println("One of the table involved in the transaction is not found" + rnf.getMessage());

} catch (InternalServerErrorException ise) {

System.err.println("Internal Server Error" + ise.getMessage());

} catch (TransactionCanceledException tce) {

System.out.println("Transaction Canceled " + tce.getMessage());

}

无论是客户端还是服务端的实现，由于 DynamoDB 采用了 W+R 的读写模式，即使事务执行成功，其他请求仍有可能读到过时的副本。不过，可以设置 ConsistentRead 参数强制读足够多的副本来获取最新的数据。

如上图的示例代码，通过以 transactWriteItems 和 transactGetItems 为核心的事务 API，几行熟悉的代码，就能实现事务的效果。

另外，为了降低网络问题导致的事务大量失败带来的用户体验问题，DynamoDB 只支持同一个 region（简单理解为 AWS 上的一个机房） 下的事务，不支持跨 region 的 global table 上的事务。

基于 BASE 的分布式事务

DynamoDB 虽好，但是如果我们已有的系统没用 DynamoDB 呢，或者用了 DynamoDB，但事务里面还包含其他数据库和服务（heterogeneous distributed transactions）呢，又该怎么办？

牺牲一致性

再回过头想想，既然 BASE 想要做的是牺牲一致性来换取可用性和性能（某种程度看也属于可用性）。那就先牺牲起来，怎么牺牲一致性呢？

回顾前面几篇文章，我们提到的单主同步、2PC 和 Paxos 这些强一致性模型，虽然差别很大，但都有一个共性：通过同步的方式做数据交互。

那想要牺牲一致性，只要改同步为异步就好了。这符合我们在系列第 8 篇讲到的内容，也正好解决了提升性能的需求。

而要做异步，最常用的就是 MQ。

举一个例子说明（来自 Ebay 的 Dan Pritchett）。

有一个电商系统，其中有 user 和 transaction 两种表，分别记录用户和交易信息。

每产生一次交易，都会生成一条 transaction 记录，并更新 user 表里的 amt_sold 或 amt_bought 字段。很明显，这两个表的数据是需要关联一致的。

一开始，ACID 下的事务就够用了：

begin transaction

insert into transaction(xid, seller_id, buyer_id, amount);

update user set amt_sold=amt_sold+$amount where id=$seller_id;

update user set amt_bought=amt_bought+$amount where id=$buyer_id;

end transaction

改造成 BASE 之后的伪代码大概会是这样：

begin transaction

insert into transaction(xid, seller_id, buyer_id, amount);

queue message "update user("seller", seller_id, amount)";

queue message "update user("buyer", buyer_id, amount)";

end transaction

for each message in queue

begin transaction

dequeue message

if message.balance = "seller"

update user set amt_sold=amt_sold+message.amount where id=message.id

else

update user set amt_bought=amt_bought+message.amount where id=message.id

end if

end transaction

end for

引入 MQ 解耦后，两张表的更新不在一个事务内完成，数据的强一致性就没有保障了，但性能得到大幅提升。

找回一致性

牺牲一致性是暂时的妥协，不是放弃，最终一致性还是要保证的。

怎么保证呢？要解决问题就要先找到问题。

先看看可能出现一致性的几个地方：

• 插入 user 表和向 MQ 发送消息，这两个操作的事务性怎么保障

• dequeue message 和向 user 表插入数据，这两个操作的事务性又怎么保证

其实就是 数据库和 MQ 的异构事务性保证 。

第一个办法，很容易想到 2PC 不然之前白讲了呵呵） 。这样就需要 MQ 支持消息的预提交，比如 RocketMQ 就支持。

• 第一阶段，发起数据库事务，并向 MQ 预提交消息。

• 第二阶段，如果数据库事务执行成功，则向 MQ 正式提交消息，否则取消消息或不正式提交后超时丢弃。

当然，由于数据库已经支持事务了，实际写法上不是严格的两阶段，而是把消息的预提交和正式提交/回滚嵌入到数据库的事务代码内。伪代码简单示例如下：

begin transaction

try

database.update_row()

mq.prepare_message()

except

database.rollback()

mq.cancle_message()

else

database.commit()

mq.commit_message()

end transaction

生产消息的事务解决了，消费消息的事务也类似，利用 MQ 的 ACK 功能实现。

可是，如果系统里使用的 MQ 不支持消息预提交呢，又怎么实现异构事务？

begin transaction

try

database.update_row()

mq.commit_message()

except

database.rollback()

else

database.commit()

end transaction

所谓幂等，就是同样的操作无论执行多少次，产生的结果都是一样的。比如 a = 1 就是幂等的， a++ 就不是幂等的。

所以有第二个办法，需要下游消息的消费方支持 幂等 操作。

所谓幂等，就是同样的操作无论执行多少次，产生的结果都是一样的。比如 a = 1 就是幂等的， a++ 就不是幂等的。

一个最简单的保证幂等的办法，就是给每条消息一个唯一的 id，下游维护一个已经消费过的消息 id 的缓存，每次消费消息的时候，检查这个 id，如果在缓存里，表示已经处理过，就应该丢弃掉。

（这里又涉及到我们已经提到过好几次的 exactly once 问题，更加完善的处理方法，还是等到后面系统再聊。）

这样，一个提供 BASE 保证的分布式系统就成型了。

我们就通过 MQ 异步解耦，提升了系统整体性能。与之而来的代价，就是只能提供最终一致性（E），流程中会出现中间状态（S）。

而解耦之后的系统，部分组件的失败，也只会导致部分的不可用，而能最大程度保留系统整体的可用性（BA）。

TL;DR

• 单机事务自动演化到分布式场景下，得到类似 ACID on 2PC 的方案，但性能和可用性都不够好。

• BASE 降低了对一致性的追求，以便获得更好的可用性和性能。

• 上面文章介绍过 Dynamo，是典型的最终一致性的分布式数据库，很容易想到用来实现 BASE。

• DynamoDB 可以有客户端和服务端两种方式实现事务。

• 如果没有用或不只用了 DynamoDB，需要自己实现异构事务。

• 可以基于 2PC 实现异构 BASE 事务。

• 也可以通过支持幂等来实现异构 BASE 事务。

系列第 10 篇我们介绍了强一致性下的分布式事务，这篇又了解了弱一致性下的分布式事务。

紧接着就面临一个问题：什么时候该用哪个？

（如果你还在问 哪个更好  这样的问题，那你需要逐渐习惯，往往没有最好，只有 trade-off 下的更好。）

两种模型的优缺点都非常明显，所以都没办法一统天下，也没办法被取代。需要我们自己，根据应用场景灵活选择。

比如 Amazon 上的商品详情页里的库存数量，不需要时时准确但访问量巨大，就可以用 BASE；而如果你的系统里有现金转账的功能，你对赔钱的担忧又远超对性能的抱怨，那就可以考虑继续 2PC 下的 ACID。

好了，分布式事务的介绍就到此为止。有心的人应该可以发现，我是从数据一致性逐渐引出分布式事务这个主题的。这是我写这个系列的思路的延续，所以会有侧重点。

所以，我并没有想要穷举所有分布式事务的实现方案，比如 TCC 只提了下，SAGA 甚至都没提。也没有仔细去讲事务里面非常重要的隔离性（Isolation level）在各个实现下的体现。有兴趣的同学，可以再额外去了解。

下一篇，是数据一致性这个章节的最后一篇。我们一起来总结下，一致性问题产生的根源在哪里。