Multi-Paxos
Basic Paxos只能就单个值(Value)达成共识,Multi-Paxos是通过多个Basic Paxos实例实现一系列值的共识的算法。
Multi-Paxos通过引入Leader节点,将Leader节点作为唯一提议者,避免了多个提议者同时提交提案的情况,解决了提案冲突的问题, Leader节点是通过执行Basic Paxos算法,进行投票选举产生的。
优化Basic Paxos执行可以采用“当领导者处于稳定状态时,省掉准备阶段,直接进入接受阶段”这个优化机制。在Leader节点上,序列中的命令是最新的,不再需要通过准备请求来发现之前被大多数节点通过的提案,Leader可以独立指定提案中的值。Leader节点在提交命令时,可以省掉准备阶段,直接进入到接受阶段:
和重复执行Basic Paxos相比,Multi-Paxos引入领导者节点之后,因为只有领导者节点一个提议者,所以就不存在提案冲突。另外,当主节点处于稳定状态时,就省掉准备阶段,直接进入接受阶段,所以在很大程度上减少了往返的消息数,提升了性能,降低了延迟。
四、一致hash算法
==========
使用哈希算法的问题?
通过哈希算法,每个key都可以寻址到对应的服务器,比如,查询key是key-01,计算公式为hash(key-01) %3 ,经过计算寻址到了编号为1的服务器节点A; 如果服务器数量发生变化,基于新的服务器数量来执行哈希算法的时候,就会出现路由寻址失败的情况,无法找到之前寻址到的那个服务器节点;假如增加了一个节点,节点的数量从3变化为4,那么之前的hash(key-01) %3 = 1,就变成了hash(key-01) %4 =X,因为取模运算发生了变化,所以这个X大概率不是1,这时再查询就会找不到数据了,因为key-01对应的数据并非存储在节点X。
通过上图可以看出,当扩容增加一个节点时会出现hash寻址失败的情况;同理,如果需要下线1个服务器节点,也会存在类似的可能查询不到数据的问题。
一致哈希实现哈希寻址
一致哈希算法也用了取模运算,但与哈希算法不同的是,哈希算法是对节点的数量进行取模运算,而一致哈希算法是对2^32进行取模运算。在一致哈希中,可以通过执行哈希算法将节点映射到哈希环上,如选择节点的主机名作为参数执行hash(),那么每个节点就能确定其在哈希环上的位置了。
当需要对指定key的值进行读写的时候,可以通过下面2步进行寻址:
首先,将key作为参数执行hash()计算哈希值,并确定此key在环上的位置;
然后,从这个位置沿着哈希环顺时针“行走”,遇到的第一节点就是key对应的节点。
根据一致哈希算法,key-01将寻址到节点A,key-02将寻址到节点B,key-03将寻址到节点C。假设现在节点C故障了,key-01和key-02不会受到影响,只有key-03的寻址被重定位到A。在一致哈希算法中,如果某个节点宕机不可用了,那么受影响的数据仅仅是会寻址到此节点和前一节点之间的数据。比如当节点C宕机了,受影响的数据是会寻址到节点B和节点C之间的数据(例如key-03),寻址到其他哈希环空间的数据不会受到影响。同理,如果集群扩容一个节点,在一致哈希算法中,如果增加一个节点,受影响的数据仅仅是会寻址到新节点和前一节点之间的数据,其它数据也不会受到影响。
在哈希寻址中常出现这样的问题:客户端访问请求集中在少数的节点上,出现了有些机器高负载,有些机器低负载的情况,在一致哈希中可以使用虚拟节点让数据访问分布的比较均匀。
使用虚拟节点解决冷热不均的问题:
对每一个服务器节点计算多个哈希值,在每个计算结果位置上,都放置一个虚拟节点,并将虚拟节点映射到实际节点。
比如,可以在主机名的后面增加编号,分别计算 “Node-A-01”“Node-A-02”“Node-B-01”“Node-B-02”“Node-C-01”“Node-C-02”的哈希值,于是形成6个虚拟节点;增加了节点后,节点在哈希环上的分布就相对均匀了。如果有访问请求寻址到“Node-A-01”这个虚拟节点,将被重定位到节点A。
因此,当节点数越多的时候,使用哈希算法时,需要迁移的数据就越多,使用一致哈希时,需要迁移的数据就越少。所以相比hash算法, 一致哈希算法具有较好的容错性和可扩展性。
五、zab协议
Multi-Paxos解决的是一系列值如何达成共识的问题,不关心最终达成共识的值是什么,不关心各值的顺序,即它不关心操作的顺序性。
ZAB协议基于主备模式的原子广播,最终实现了操作的顺序性。Master-Slave的主备模型,主节点采用二阶段提交,向备份节点同步数据,如果主节点发生故障,数据最完备的节点将当选主节点;原子广播协议,广播一组消息,消息的顺序是固定的。
ZAB支持3种成员身份(领导者、跟随者、观察者)。
领导者(Leader): 作为主节点,在同一时间集群只会有一个领导者,所有的写请求都必须在领导者节点上执行。
**跟随者(Follower):**作为备份节点, 集群可以有多个跟随者,它们会响应领导者的心跳,并参与领导者选举和提案提交的投票,跟随者可以直接处理并响应来自客户端的读请求,但对于写请求,跟随者需要将它转发给领导者处理。
**观察者(Observer):**作为备份节点,类似跟随者,但是没有投票权,观察者不参与领导者选举和提案提交的投票。
ZAB在Multi-Paxos的基础上做了优化,为了实现分区容错能力,将数据复制到大多数节点后,领导者就会进入提交执行阶段,通知备份节点执行提交操作。
ZAB定义了4种成员状态:
**LOOKING:**选举状态,该状态下的节点认为当前集群中没有领导者,会发起领导者选举。
**FOLLOWING :**跟随者状态,意味着当前节点是跟随者。
**LEADING :**领导者状态,意味着当前节点是领导者。
**OBSERVING:**观察者状态,意味着当前节点是观察者。
如上图所示, 首先,当跟随者检测到连接领导者节点的读操作等待超时了,跟随者会变更节点状态,将自己的节点状态变更成LOOKING,然后发起领导者选举; 接着,每个节点会创建一张选票,这张选票是投给自己的,然后各自将选票发送给集群中所有节点, 一般而言,节点会先接收到自己发送给自己的选票(因为不需要跨节点通讯,传输更快); 集群的各节点收到选票后,为了选举出数据最完整的节点,对于每一张接收到选票,节点都需要进行领导者PK,也就将选票提议的领导者和自己提议的领导者进行比较,找出更适合作为领导者的节点,约定的规则如下:
-
优先检查任期编号(Epoch),任期编号大的节点作为领导者;
-
如果任期编号相同,比较事务标识符的最大值,值大的节点作为领导者;
-
如果事务标识符的最大值相同,比较集群ID,集群ID大的节点作为领导者。
如果选票提议的领导者,比自己提议的领导者,更适合作为领导者,那么节点将调整选票内容,推荐选票提议的领导者作为领导者。
zab故障恢复是由成员发现和数据同步两个阶段完成的,成员发现是通过跟随者和领导者交互来完成的,目标是确保大多数节点对领导者的领导关系没有异议,也就是确立领导者的领导地位:
成员发现,是为了建立跟随者和领导者之间的领导者关系,并通过任期编号来确认这个领导者是否为最合适的领导者。 当跟随者和领导者设置ZAB状态为数据同步,它们也就是进入了数据同步阶段,数据同步也是通过跟随者和领导者交互来完成的,目标是确保跟随者节点上的数据与领导者节点上数据是一致的。
数据同步,是通过以领导者的数据为准的方式,来实现各节点数据副本的一致,需要你注意的是,基于“大多数”的提交原则和选举原则,能确保被复制到大多数节点并提交的提案,就不再改变。
对于zab处理写请求:
由于写请求只能在领导者节点上处理,所以ZooKeeper集群写性能约等于单机。而读请求是可以在所有的节点上处理的,所以读性能是能水平扩展的。可以通过分集群的方式来突破写性能的限制, 并通过增加更多节点,来扩展集群的读性能。
首先,ZAB实现了主备模式,也就是所有的数据都以主节点为准;
其次,ZAB实现了FIFO队列,保证消息处理的顺序性。
另外,ZAB还实现了当主节点崩溃后,只有日志最完备的节点才能当选主节点,因为日志最完备的节点包含了所有已经提交的日志,所以这样就能保证提交的日志不会再改变。
六、raft算法
========
Raft算法是分布式系统开发首选的共识算法 ,从本质上说,Raft算法是通过一切以领导者为准的方式,实现一系列值的共识和各节点日志的一致。
Raft算法支持领导者(Leader)、跟随者(Follower)和候选人(Candidate)3种状态:
**跟随者:**就相当于普通群众,默默地接收和处理来自领导者的消息,当等待领导者心跳信息超时的时候,就主动站出来,推荐自己当候选人。
**候选人:**候选人将向其他节点发送请求投票(RequestVote)RPC消息,通知其他节点来投票,如果赢得了大多数选票,就晋升当领导者。
**领导者:**主要工作内容就是3部分,处理写请求、管理日志复制和不断地发送心跳信息。
选举领导者的过程:
首先,在初始状态下,集群中所有的节点都是跟随者的状态,每个节点等待领导者节点心跳信息的超时时间间隔是随机的。集群中没有领导者,而节点A的等待超时时间最小(150ms),它会最先因为没有等到领导者的心跳信息而发生超时。节点A就增加自己的任期编号,并推举自己为候选人,先给自己投上一张选票,然后向其他节点发送请求投票RPC消息,请求它们选举自己为领导者。当候选人节点A在选举超时时间内赢得了大多数的选票,那么它就会成为本届任期内新的领导者。
节点A当选领导者后,将周期性地发送心跳消息,通知其他服务器以阻止跟随者发起新的选举。
Raft算法中约定的选举规则:
-
领导者周期性地向所有跟随者发送心跳消息,阻止跟随者发起新的选举。
-
如果在指定时间内,跟随者没有接收到来自领导者的消息,那么它就认为当前没有领导者,推举自己为候选人,发起领导者选举。
-
在一次选举中,赢得大多数选票的候选人,将晋升为领导者。
-
在一个任期内,领导者一直都会是领导者,直到它自身出现问题(比如宕机),或者因为网络延迟,其它节点发起一轮新的选举。
-
在一次选举中,每一个服务器节点会按照“先来先服务”的原则进行投票。
-
当任期编号相同时,日志完整性高的跟随者(最后一条日志项对应的任期编号值更大,索引号更大),拒绝投票给日志完整性低的候选人。比如节点B、C的任期编号都是3,节点B的最后一条日志项对应的任期编号为3,而节点C为2,那么当节点C请求节点B投票给自己时,节点B将拒绝投票。
Raft算法日志复制流程:
Raft算法中,副本数据是以日志的形式存在的,领导者接收到来自客户端写请求后,处理写请求的过程就是一个复制和应用日志项到状态机的过程。
首先,领导者进入第一阶段,通过日志复制(AppendEntries)RPC消息,将日志项复制到集群其他节点上。
接着,如果领导者接收到大多数的“复制成功”响应后,它将日志项应用到它的状态机,并返回成功给客户端。如果领导者没有接收到大多数的“复制成功”响应,那么就返回错误给客户端。
1. 接收到客户端请求后,领导者基于客户端请求中的指令,创建一个新日志项,并附加到本地日志中。
2. 领导者通过日志复制RPC,将新的日志项复制到其他的服务器。
3. 当领导者将日志项成功复制到大多数的服务器上的时候,领导者会将这条日志项应用到它的状态机中。
4. 领导者将执行的结果返回给客户端。
5. 当跟随者接收到心跳信息,或者新的日志复制RPC消息后,如果跟随者发现领导者已经提交了某条日志项,而它还没应用,那么跟随者就将这条日志项应用到本地的状态机中。
总结
==
ZAB协议在Multi-Paxos达成共识的基础上实现了操作的顺序性。
Raft算法和Multi-Paxos不同之处:
1. 在Raft中,不是所有节点都能当选领导者,只有日志最完整的节点,才能当选领导者;
2. 日志必须是连续的;
Raft算法与ZAB协议的异同点:
1. Raft采用的是“先到先得”的自定义投票算法。Raft的领导者选举,需要通讯的消息数更少,选举也更快。
2. 对于日志复制,Raft和ZAB相同,都是以领导者的日志为准来实现日志一致,而且日志必须是连续的,也必须按照顺序提交。
3. 对于读操作和一致性,ZAB的设计目标是操作的顺序性,在ZooKeeper中默认实现的是最终一致性,读操作可以在任何节点上执行;而Raft的设计目标是强一致性(也就是线性一致性),所以Raft更灵活,Raft系统既可以提供强一致性,也可以提供最终一致性。
4. 对于写操作,Raft和ZAB相同,写操作都必须在领导者节点上处理。
5. 成员变更,ZAB不支持成员变更,当需要节点变更(比如扩容)时,必须重启整个ZooKeeper集群。Raft支持成员变更,不需要重启机器,集群是一直运行的,服务也不会中断。
相比ZAB,Raft的设计更为简洁,Raft没有引入类似ZAB的成员发现和数据同步阶段,而是当节点发起选举时,递增任期编号,在选举结束后,广播心跳,直接建立领导者关系,然后向各节点同步日志,来实现数据副本的一致性。
以上就是有关分布式的学习笔记,希望可以对大家有帮忙,喜欢的小伙伴可以帮忙转发+关注,有需要的可以下方扫码来获取~感谢大家!
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
![img](https://i-blog.csdnimg.cn/blog_migrate/177de69558a220955aa7cd22776d71a3.jpeg)
最后
小编在这里分享些我自己平时的学习资料,由于篇幅限制,pdf文档的详解资料太全面,细节内容实在太多啦,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
程序员代码面试指南 IT名企算法与数据结构题目最优解
这是” 本程序员面试宝典!书中对IT名企代码面试各类题目的最优解进行了总结,并提供了相关代码实现。针对当前程序员面试缺乏权威题目汇总这一-痛点, 本书选取将近200道真实出现过的经典代码面试题,帮助广“大程序员的面试准备做到万无一失。 “刷”完本书后,你就是“题王”!
《TCP-IP协议组(第4版)》
本书是介绍TCP/IP协议族的经典图书的最新版本。本书自第1版出版以来,就广受读者欢迎。
本书最新版进行」护元,以体境计算机网络技不的最新发展,全书古有七大部分共30草和7个附录:第一部分介绍一些基本概念和基础底层技术:第二部分介绍网络层协议:第三部分介绍运输层协议;第四部分介绍应用层协议:第五部分介绍下一代协议,即IPv6协议:第六部分介绍网络安全问题:第七部分给出了7个附录。
Java开发手册(嵩山版)
这个不用多说了,阿里的开发手册,每次更新我都会看,这是8月初最新更新的**(嵩山版)**
MySQL 8从入门到精通
本书主要内容包括MySQL的安装与配置、数据库的创建、数据表的创建、数据类型和运算符、MySQL 函数、查询数据、数据表的操作(插入、更新与删除数据)、索引、存储过程和函数、视图、触发器、用户管理、数据备份与还原、MySQL 日志、性能优化、MySQL Repl ication、MySQL Workbench、 MySQL Utilities、 MySQL Proxy、PHP操作MySQL数据库和PDO数据库抽象类库等。最后通过3个综合案例的数据库设计,进步讲述 MySQL在实际工作中的应用。
Spring5高级编程(第5版)
本书涵盖Spring 5的所有内容,如果想要充分利用这一领先的企业级 Java应用程序开发框架的强大功能,本书是最全面的Spring参考和实用指南。
本书第5版涵盖核心的Spring及其与其他领先的Java技术(比如Hibemate JPA 2.Tls、Thymeleaf和WebSocket)的集成。本书的重点是介绍如何使用Java配置类、lambda 表达式、Spring Boot以及反应式编程。同时,将与企业级应用程序开发人员分享一些见解和实际经验,包括远程处理、事务、Web 和表示层,等等。
JAVA核心知识点+1000道 互联网Java工程师面试题
企业IT架构转型之道 阿里巴巴中台战略思想与架构实战
本书讲述了阿里巴巴的技术发展史,同时也是-部互联网技 术架构的实践与发展史。
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
人员分享一些见解和实际经验,包括远程处理、事务、Web 和表示层,等等。
[外链图片转存中…(img-Gn4uQCB6-1712835261392)]
JAVA核心知识点+1000道 互联网Java工程师面试题
[外链图片转存中…(img-v3veLD1n-1712835261392)]
[外链图片转存中…(img-uH8WUiSL-1712835261393)]
企业IT架构转型之道 阿里巴巴中台战略思想与架构实战
本书讲述了阿里巴巴的技术发展史,同时也是-部互联网技 术架构的实践与发展史。
[外链图片转存中…(img-4PL82JT3-1712835261393)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!