两阶段提交1次日志2rpc疑问

第一张图的出处麻烦发下

@论坛小助手

根据您提供的两张图及其描述，可以看出它们分别展示了传统两阶段提交（2PC）协议与 OceanBase 数据库中优化后的两阶段提交协议的不同之处。下面我将针对您的疑问进行详细解释：

1. 关于“2RPC”的疑问：

   • 传统两阶段提交协议中，协调者（Coordinator）需要向所有参与者（Participants）发起两次远程过程调用（RPC），一次是在准备阶段（Prepare Phase），另一次是在提交或回滚阶段（Commit/Rollback Phase）。 [1]
   • 第一张图中的流程展示了一个典型的两阶段提交过程，其中包含两次远程调用：一次是发送准备请求（Prepare Request），一次是发送提交请求（Commit Request）。 [2]
   • 而在 OceanBase 的优化方案中，引入了预提交(pre-commit)阶段，这使得整个流程变得更加复杂，但同时也减少了最终提交或回滚阶段所需的 RPC 调用次数。 [1]

2. 两张图的对比：

   • 第一张图（a）显示了传统的两阶段提交协议，其中包含两次 RPC 调用，一次用于准备(prepare)，一次用于提交(commit)。 [2]
   • 第二张图则展示了 OceanBase 的改进版本，增加了预提交(pre-commit)步骤，并且在完成预提交后会通知客户端，这意味着相较于传统方法，OceanBase 的方案在某些情况下可以减少一次 RPC 调用。 [3]

3. 是否存在冲突：

   • 实际上这两张图并不矛盾，它们只是展示了不同版本或不同实现方式下的两阶段提交过程。传统 2PC 与 OceanBase 优化后的 2PC 在设计理念上有区别，前者更注重事务的原子性和一致性，后者则在此基础上进一步优化了性能，尤其是在减少网络延迟方面做出了改进。 [2]

综上所述，“2RPC”指的是两次远程过程调用，这是两阶段提交协议的核心特征之一。而两张图之间的差异反映了 OceanBase 在传统 2PC 基础上所做的创新，旨在提升系统性能的同时保证事务的正确性。希望以上解释能帮助您更好地理解两阶段提交协议及其在 OceanBase 中的具体实现。

更多信息请查看:

1. XA 事务
2. 两阶段提交
3. 并发控制概述
4. 副本介绍
5. 分布式事务概述
6. 日志归档概述
7. 本地事务
8. Redo 日志

https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000821584

这个就是1次log2次rpc，黄色的是log持久化，虚线箭头是rpc，从协调者到参与者就是2次rpc的

OB对两阶段提交做了优化，prepare阶段完成就认为事务已经提交成功了，这时候用户就已经收到commit ok的返回信息了，后面的commit阶段和clear阶段可以认为是对用户是无感知的。

你说的是那个图 ？？？

这个图就可以提现1次log2次rpc的，用户感知的只是prepare log的持久化延迟，和协调者发送prepare req的rpc以及参与者返回的prepare ok的rpc

能帮忙标出 那个是 2次 rpc 那个是 1次log不？

参考一下这个帖子看看符合你的问题么

课程
https://open.oceanbase.com/course/detail/9258

再20分到21分讲的 ， 多了一次rpc延迟是为了增加版本号

实在没明白 什么叫做日志延迟？ 什么叫做rpc延迟？

这个老师讲的 。

发送2次rpc，也就是2次rpc延迟的意思，写一次prepare log 也叫做1次日志延迟

image1340×1022 51.8 KB

要是您回答的正确的话，这个官方的图无法体现出 2次 rpc延迟， 能否修正下呢 ？

文档应该需要更新下，感谢你的反馈

image1920×1011 55.8 KB

image1920×905 54.6 KB

image1313×723 100 KB

是否和你说的有冲突？？？

也不是说冲突，这个文档这里解释的比较简单，没有述说pre commit阶段，这里是1次日志延迟+1次RPC延迟，下面这篇文章是这个的原理版本，当然4.x这里放这个图不太合适
https://open.oceanbase.com/blog/27200124

官方文档里的两阶段提交就是没提到pre commit和 clear log 这个两个阶段罢了，楼主你就看阶段最复杂的那个就行了。

协调者无状态，不再持久化日志，

prepare阶段完成之间返回客户端 提交成功

这是2句话就解释清楚了。

为了优化2PC性能 优化思路如下：

• 协调者无状态，不再持久化日志，但是为了方便宕机重启后恢复事务状态，需要向每个参与者发送事务的参与者名单并持久化。这样即使协调者宕机，参与者也可以方便地询问其他参与者事务状态了。

• 只要所有参与者prepare成功，事务一定会成功提交。

因此为了减少提交延时，协调者可以在收到所有参与者prepare成功后就返回客户端成功

2阶段提交 ob如何响应延迟从4次日志延迟+2次RPC 从 降低到1次日志延迟+1次PRC延迟

2次RPC 减少到 1次PRC延迟

是通过 prepare阶段完成之间返回客户端 提交成功

协调者：协调者收齐所有参与者的 prepare ack 之后，

1. 进入 COMMIT 状态，向用户返回事务 commit 成功 【1次rpc】

2. 然后向所有参与者发送事务 commit request

4次日志延迟 降低到1次日志延迟

协调者 不在持久化日志。。

个人理解

1. prepare 节点决定 2阶段提交是否成功，如果在accept节点 如果节点故障，
   通过协调者 持久化日志 来进行恢复出来。prepare 返回也合理
2. 2阶段 原来方式协调者 可能单点，为了解决故障问题，持久化合理 ,现在多节点了，可以不持久化
3. raft paxos 协议节点故障后，不在查询其他节点状态判断事物状态，这个肯定的。怎么恢复不清楚。

image1993×1018 148 KB

image1960×1051 132 KB

这是他们内部术语，

• 日志延迟 是经过持久化 ，例如 提案编号，提案内容。优化协调者不持久化日志就清楚了

• rpc延迟 针对客户端来说，就是发送给服务端，服务端经过prepare阶段 返回成功。

简单理解，客户端发送服务端，服务端 之间返回结果 类比 redis 同步方式不一定全部同步在返回成功。