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获取）
最后
小编在这里分享些我自己平时的学习资料，由于篇幅限制，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)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
156
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
