OBCP第五章 分布式事务高级技术-分布式两阶段提交

两阶段协议

2PC是一个非常经典的强一致、中心化的原子提交协议。中心化指的是协调者（Coordinator），强一致性指的是需要所有参与者（participant）均要执行成功才算成功，否则回滚。

第一阶段：协调者（coordinator)发起提议通知所有的参与者（participant），参与者收到提议后，本地尝试执行事务，但并不commit，之后给协调者反馈，反馈可以是yes或者no

第二阶段：协调者收到参与者的反馈后，决定commit或者rollback，参与者全部同意则commit，如果有一个参与者不同意则rollback

OceanBase两阶段提交协议

标准两阶段提交协议

优点：状态简单，只依靠协调者状态即可确认和推进整个事务状态

缺点：协调者写日志，commit延时高

OceanBase两阶段提交协议

协调者不写日志，变成了一个无持久化状态的状态机

事务的状态由参与者的持久化状态决定

所有参与者都prepare成功即认为事务进入提交状态，立即返回客户端commit

每个参与者都需要持久化参与者列表，方便异常恢复时构建协调者状态机，推进事务状态

参与者增加clear阶段，标记事务状态机是否终止

 

 

OB两阶段提交

业务不感知是否分布式事务，如果只有一个参与者使用一阶段提交；否则自动使用两阶段提交

参与者的实体是 Partition（Px，Py，Pz）

指定第一个参与者 Px 作为协调者，发送 end_trans 消息给 Px 并告知参与者列表：Px，Py，Pz

OB两阶段提交延迟分析

用户感知的commit延迟

标准：4次日志延迟 + 2次RPC延迟

OB：1次日志延迟 + 2次RPC延迟

 分布式事务的高可用

如果事务在prepare状态落盘之前发生宕机，机器恢复后事务会回滚

                        

如果事务处于commit阶段，由于clog已经落盘，即 使发生宕机场景，事务都会执行完成，只是业务端可能会收到事务unknown的回复，需要业务端confirm 事务的状态

                          

两阶段提交过程中参与者宕机

还未进入Prepared状态

参与者所有事务状态丢失

参与者会应答协调者prepare unknown消息

事务最终会abort

                    

已进入Prepared状态

状态已经Paxos同步

系统会自动选择一个副本，作为新的leader并恢复

出prepare状态，协调者继续推进

            

协调者与第一个参与者是同一个partition

参与者状态机恢复遵从参与者自己的逻辑

协调者状态机恢复由参与者回复协调者的消息触发

参与者发送prepare ok后未收到协调者进一步消息（commit/abort）时，认为

上一条回复消息丢失，会定时重新发送上一条消息

所有参与者都记录全部参与者列表

分布式事务优化

分布式事务底层优化

单分区事务：不走2PC ，直接写一条日志即可完成事务提交

单机多分区事务→ 优化的两阶段提交

多机多分区事务→完整的两阶段提交 →prepare, commit/abort

分布式事务调优方法

业务数据模型设计原则：尽量避免跨机分布式事务

单sql语句不建议跨机器，通过table group、primary_zone把相关的表的leader

放在同一个机器上

慎重选择事务中的第一条语句，因为Obproxy的路由规则