两阶段协议
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/abor
分布式事务调优方法
业务数据模型设计原则：尽量避免跨机分布式事务
单sql语句不建议跨机器，通过table group、primary_zone把相关的表的leader
放在同一个机器上
慎重选择事务中的第一条语句，因为Obproxy的路由规则
