【问题标题】:Two Phase Commit and merging execution and prepare phase两个阶段提交和合并执行和准备阶段
【发布时间】:2012-11-06 10:06:53
【问题描述】:

据我所知,在两阶段提交之前甚至需要运行往返通信以将事务发送到每个站点。每个站点都会执行他们的事务部分,当协调器从所有站点获得响应时,它会运行两阶段提交。这将启动准备阶段等。

为什么必须将准备阶段与两阶段提交之前的执行分开?是否有理由不合并执行和准备阶段,从而减少往返通信成本?

这是我之前的question 的后续。

【问题讨论】:

    标签: distributed-transactions xa 2phase-commit


    【解决方案1】:

    这样做有几个很好的理由:

    1. 操作可能需要来自其他站点的数据。如果合并执行阶段和准备阶段,您将如何在不同站点的数据项之间实现 swap(a,b) 操作?
    2. 协调器很可能成为性能瓶颈。合并执行和提议阶段将使其参与中继应用程序数据,进一步使其过载。
    3. 透明度和封装。请注意,在回复您的previous question(即业务逻辑)中开始/提交之间的代码根本不涉及分布式事务。它不需要知道将涉及哪些站点,甚至是多少站点!它调用可能是(或不是...)对未知站点的远程调用的任意过程。要合并执行和准备,您必须将应用程序逻辑显式打包到每个参与者的独立回调中。

    此外,在考虑涉及持久性的性能时,您应该关注意味着刷新日志的往返。执行阶段的调用不需要刷新日志,因此应该比准备和提交阶段便宜得多。

    【讨论】:

    • (1) 你能解释一下为什么swap(a,b) 操作会阻止执行和准备阶段的合并。 (2)当您说协调器可能成为性能瓶颈时,您的意思是在2PC之前,客户端负责将2PC之前的事务发送到所有站点而不是协调器? (3) 最后,您是从哪里得知这些想法的?是否有一些论文详细讨论了尝试这种合并执行和准备的想法的负面影响?
    猜你喜欢
    • 2011-11-15
    • 2011-11-24
    • 2013-05-21
    • 2014-09-12
    • 2015-02-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多