1 个赞
这是原生分布式的能力，在写入的时候就要求多数派返回成功本地才能返回成功，传统两阶段提交是要在本地先落盘在通知其他节点，写日志和RPC交互就多。
1 个赞
嗯嗯，谢谢。不知道具体是哪四次？
图里标黄色的都是写日志。
传统是协调者1次，执行者各1次，但从应用感知相当于一次，然后协调者再1次，执行者再各1次
ob是协调者无状态，不写日志，就执行者写一次，然后就返回应用了，所以应用感知就是1次写日志，虽然后面执行者还会写一次，但事务已经正常返回了
原生分布式就是效率高
多数派强同步
看黄色的图形的话，这不是6次吗？
对比OB不是多了4次吗。。
传统两阶段提交协议的日志写入次数
协调者两次日志写入：
在 PREPARE 阶段，协调者需要记录日志以确认所有参与者已准备就绪；
在 COMMIT/ABORT 阶段，协调者再次记录日志以确定最终提交或回滚结果。
参与者两次日志写入：
在 PREPARE 阶段，每个参与者记录本地事务状态（如锁定数据）；
在 COMMIT/ABORT 阶段，参与者记录最终提交或回滚操作。
总计：协调者（2次） + 参与者（2次，假设单个参与者）= 4次日志写入
OceanBase 的优化措施
(1) 协调者无状态设计
省去协调者日志写入：
传统协调者需维护全局事务状态，依赖日志恢复故障，导致两次日志写入。
OceanBase 的协调者无状态，不记录任何事务状态。其决策完全依赖参与者反馈，故障恢复时通过参与者局部状态动态重建全局状态，从而避免协调者两次日志写入。
(2) 参与者日志写入合并
仅需一次日志写入：
参与者在 PREPARE 阶段记录日志后，后续的 COMMIT/ABORT 阶段无需额外日志。因为协调者无状态，参与者通过 Paxos 协议的多数派副本确保数据一致性，无需重复记录。
日志共享与批量提交：
通过 Batch Commit 优化，多个参与者的 PREPARE 日志可合并写入，减少 I/O 开销。
1 个赞
ppt里说了是用户感知的，两个参与者是并行处理的，所以对于用户感知来说只有1次，夸张点如果有几百个参与者，用户感知也相当于1次写日志。
1 个赞