在article on BASE as an ACID alternative 中，Dan Pritchett 提出了一种用于将跨越两个表的事务解耦的选项，Transaction 表（例如买/卖交易）和 User 表：
Dan 还认为这种方法存在问题：
消息持久化在事务主机上，避免2PC 排队期间。如果消息在事务中出列 涉及到用户主机，我们还是有2PC的情况。
我假设消息传递是持久消息传递，因此可以保证传递。在这种情况下，我希望 Dequeue 操作对 Queue 操作没有影响，从而完全解耦 Transaction 和 User 表的更新，从而避免这两个表之间的 2PC表？会有 2PC，但那将是：
2PC边界1：
2PC边界2：
有人能澄清我在哪里考虑这个错误吗？
【问题讨论】：
标签： database transactions message-queue acid eventual-consistency
会有 2PC，但那将是：
TL;DR：您对这两个事务的看法是正确的，但第一个是不是 2PC，而第二个是。这就是图 5 所描述的。 2PC 是“我们仍然存在 2PC 情况”的原因。
文章有一些困难。 transaction 表与数据库事务无关，应称为purchases。 “持久队列”只是一个代表更改队列的表。此外，它不断提出有“问题”的非解决方案。
使用 BASE 的提议涉及将用户表替换为两个表 user_less_delta 和 delta，它们共同提供与 user 相同的信息。 （然后它使用“user”代替user_less_delta，但我将使用单独的名称。）但是delta 与purchases 一起保存在主机上。即它不需要2PC来实现涉及purchases和delta的事务，但需要2PC来实现涉及user_less_delta和delta的事务。
图 5 BASE 松弛是用delta 原子地处理purchases（没有2PC）然后分别用delta 原子地2PC 处理user_less_delta 的各种更改。这使我们不必每次更新到user_less_delta 和purchases 2PC，代价是user_less_delta 不如user 准确。然而，这仍然假设
2PC 用于更新user_less_delta 和delta。
我不知道你所说的“边界”是什么意思。 （“持久消息传递”等其他语言也不清楚。）但是有两种事务：purchases 上的非 2PC 事务delta 和user_less_delta 上的 2PC 事务delta。
Dan 还认为这种方法存在问题：
消息持久化在事务主机上，避免排队时出现2PC。如果消息在涉及用户主机的事务中出列，我们仍然有 2PC 的情况。
此解决方案的“问题”是仍然涉及 2PC。 “If”应该只是“Since”，否则代码无法正确实现分布式表。由于消息在涉及用户主机的事务中出列，我们仍然有 2PC 的情况。
该文章继续（据称）删除 2PC，方法是让 delta 反映在没有 2PC 的 user_less_delta 中，但在另一种情况下让 user_less_delta 反映在 delta 中而没有 2PC。 delta 中已处理的更改将被忽略。 （等等！我还没有读到那么远！好的，现在我读到了，这就是他们的建议。）
（基本上，每个分布式站点尝试更新和确认对方，并在收到确认时推进其已确认和尚未确认的版本。一种红皇后的竞赛完成一个 2PC。）
【讨论】：