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如何保证一致性
严重:
多数派节点宕机:此时服务中断,需要重启宕机进行副本恢复。
集群全部宕机:此时服务中断,需要重启宕机进行副本恢复。