1

在一篇关于 BASE 作为 ACID 替代方案的文章中，Dan Pritchett 提出了一个用于解耦跨越两个表的事务的选项，事务表（例如购买/出售事务）和用户表：

在此处输入图像描述

来源： http://queue.acm.org/detail.cfm?id= 1394128

Dan 还认为这种方法存在问题：

消息持久化在事务主机上，以避免排队期间的 2PC。如果消息在涉及用户主机的事务中出列，我们仍然有 2PC 的情况。

来源： http://queue.acm.org/detail.cfm?id= 1394128

我假设消息传递是持久消息传递，因此可以保证传递。在这种情况下，我希望 Dequeue 操作对 Queue 操作没有影响，从而完全解耦Transaction和User表的更新，从而避免这两个表之间的 2PC？将有 2PC，但这将是：

  • 2PC边界1：

    • 插入事务表 AND
    • 插入消息队列消息持久化表

  • 2PC边界2：

    • 更新用户表 AND
    • 从消息队列持久表中删除消息

有谁能够澄清我在哪里思考这个错误？

4

1 回答 1

1

将有 2PC，但这将是：

TL; DR：您对两笔交易是正确的，但第一笔不是2PC，而第二笔是。这就是图 5 所描述的。2PC 就是为什么“我们仍然有 2PC 的情况”。

文章有一些困难。该transaction表与数据库事务无关，应称为purchases. “持久队列”只是一个代表更改队列的表。此外，它不断提出有“问题”的非解决方案。

使用 BASE 的提议涉及用两个表替换用户表user_less_delta，delta它们一起提供与user. （然后它使用“ user”表示，user_less_delta但我将使用单独的名称。）但是delta在主机上使用purchases. 即它不需要 2PC 来实现涉及purchaseswith的事务，delta但确实需要 2PC 来实现涉及user_less_deltawith的事务delta。

图 5 BASE 松弛是原子地处理（没有 2PC）purchases，delta然后分别原子地处理 2PC 的各种user_less_delta变化delta。这使我们不必在每次更新时都进行 2PC 更新user_less_delta，purchases但代价是user_less_delta不如user. 然而，这仍然假设 2PCs 用于user_less_delta更新delta。

我不知道你所说的“边界”是什么意思。（“持久消息传递”等其他语言也不清楚。）但是有两种事务：在 with 上的非 2PC 事务和在withpurchases上的delta2PC 事务。user_less_deltadelta

Dan 还认为这种方法存在问题：

消息持久化在事务主机上，以避免排队期间的 2PC。如果消息在涉及用户主机的事务中出列，我们仍然有 2PC 的情况。

此解决方案的“问题”是仍然涉及 2PC。“If”应该只是“Since”，否则代码无法正确实现分布式表。由于消息在涉及用户主机的事务中出列，我们仍然有 2PC 的情况。

该文章继续（据称）通过以一种速率反映在没有 2PC 的情况下但在另一种情况下delta反映在没有 2PC 的情况下来移除2PC。已处理的更改将被忽略。（等等！我还没有读到那么远！好的，现在我有，这就是他们的建议。）user_less_deltauser_less_deltadeltadelta

（基本上每个分布式站点都会尝试更新和确认另一个站点，并且在收到确认时会推进其已确认和尚未确认的版本。一种完成 2PC 的红皇后竞赛。）

于 2015-02-27T23:07:46.867 回答