OceanBase 3.X 高可用 （一）

OceanBase 3.X 高可用（一）

一、分布式核心

OceanBase 3.x 采用的是paxos 协议，与raft协议相比。其复杂程度高，实现技术难度大。

Paxos 协议允许事务日志乱序发送，顺序提交。raft允许事务顺序发送，顺序提交。相比之下，paxos协议的事务执行速度将快于raft协议。

Paxos 与 Raft 都对节点网络延迟与时钟同步有要求，Paxos对网络抖动，性能影响方面都优于raft协议。
Raft算法认为各副本都是对等的，那么在leader选举机制上会弱于Paxos（会根据系统硬件，资源配置，负载均衡进行判断）。

二、Leader 选举

1.Leader选举会由其中一台Server 充当提议者，其它Server 充当 接受者。提议者会向充当者发送提议【编号与value】，如果充当者中的大多数都接收到了消息并进行了回复，则提议者当选为Leader。

2.当选Leader的Server会将【编号与value】发送给所有的接受者，如果多数接受者返回了AcceptAck()，说明大多数接受者已认同。

3.Leader 这个提议者将向所有的接受者发送Accept【编号与value】。

感觉上有点偏向TCP的三次握手。

多个Server 当选 为Leader的问题（相近的时间内，多个Server完成了上面动作），产生脑裂问题的解决办法：

Paxos 协议因为是基于时钟同步的(时钟也是集群)。
在无主的情况下，第一个Server当选为Leader，会存在一个lease（租约时间，未过期状态下）。
当有Leader存在租约时间且小于其Server中的leader lease小(且不过期的情况下)，则只会认为拥有最小lease的Server充当Leader。

突然联想到了注册中心实现分布式锁的原理（比如zookeeper）。

三、Leader 三种改选类型（需要考虑健康程度，硬件优势）

MAX_DELAY=100ms
MAX_TST=200ms

NTP 小于 100ms
Server 之间小于 200ms

1.有主连任：
在lease租期内，自我推荐，拥有优先权(其它Server默认其有优先权)。

2.无主选举：
1.所有的follow Observer 会发起devote_prepare（相当于当选意愿，包含了自己想要当选的权重）。
2.所有的follow Observer 在交换意愿后，推举最大意愿的follow Observer 为Leader，并向其发送devote_prepare消息（告诉最大意愿的follow Observer当选了）。且意愿低的follow observer会记录unconfirmed_leader_lease。
3.当多数派都选择了统一个Server，Server就要开始Leader上任了 ，并将好消息(成功当选)广播给所有的follow observer，follow observer们就默默记录Leader_lease了（相当于备案，防止自己不长眼，自己造时势力，准备谋反，可惜天意天命不在身呀）。
4.Leader 选举完成，开始清理所有的选举产生的临时状态信息（有点卸磨杀驴，抹掉痕迹，然后其他人感觉Leader是寿命于天、既受永昌）。

四、Leader 日志同步

1.app 发起dml ，leader 记录dml到memstore与clog，clog同步到其它follower中并重放至memstore。
2.app 发起commit，leader中的clog开始落盘，同时其它follower也开始落盘，当大多数follower都落盘OK ，则app将认为已执行成功。

因为Paxos的原因，日志是乱序发送，顺序提交。

五、Paxos如何保证一致性

严重：
多数派节点宕机：此时服务中断，需要重启宕机进行副本恢复。
集群全部宕机：此时服务中断，需要重启宕机进行副本恢复。