徐州企业做网站,wordpress 钩子大全,做标准件生意上什么网站,杭州建设网通知公告栏OceanBase 3.X 高可用#xff08;一#xff09;
一、分布式核心
OceanBase 3.x 采用的是paxos 协议#xff0c;与raft协议相比。其复杂程度高#xff0c;实现技术难度大。
Paxos 协议允许事务日志乱序发送#xff0c;顺序提交。raft允许事务顺序发送#xff0c;顺序提…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_DELAY100ms MAX_TST200ms
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.当多数派都选择了统一个ServerServer就要开始Leader上任了 并将好消息(成功当选)广播给所有的follow observerfollow observer们就默默记录Leader_lease了相当于备案防止自己不长眼自己造时势力准备谋反可惜天意天命不在身呀。 4.Leader 选举完成开始清理所有的选举产生的临时状态信息有点卸磨杀驴抹掉痕迹然后其他人感觉Leader是寿命于天、既受永昌。
四、Leader 日志同步
1.app 发起dml leader 记录dml到memstore与clogclog同步到其它follower中并重放至memstore。 2.app 发起commitleader中的clog开始落盘同时其它follower也开始落盘当大多数follower都落盘OK 则app将认为已执行成功。
因为Paxos的原因日志是乱序发送顺序提交。
五、Paxos如何保证一致性 严重 多数派节点宕机此时服务中断需要重启宕机进行副本恢复。 集群全部宕机此时服务中断需要重启宕机进行副本恢复。
