文章目录
什么是CAP定理?
CAP定理是指分布式系统中, CAP三者不可兼得
- 一致性(Consistency):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
- 可用性(Availability):保证每个请求不管成功或者失败都有响应。
- 分区容忍性(Partition tolerance):分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务。
为什么CAP不可兼得呢?
- 分布式系统,分区是必然存在的,所谓分区指的是分布式系统可能出现的字区域网络不通,成为孤立区域的的情况。
- 保证一致性。则可用性保证不了,因为要等一致
- 保证可用性。则一致性保证不了,达到一致要时间
CAP对应的模型和应用,Zookeeper,Eureka,Nacos,consoul分别属于什么架构?√
- CA(单机):放弃分区容错性,加强一致性和可用性,集群数据库、xFS文件系统
- AP:放弃一致性,分区容错性和可用性,一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。系统不保证改变提交以后立即改变集群的状态,但是随着时间的推移最终状态是一致的。->Web缓存、DNS、GOSSIP.MySQL主从异步复制\Redis \Eureka
- CP:放弃可用性,追求一致性和分区容错性,P(分区)会导致同步时间无限延长,网络问题会直接让整个系统不可用.保证系统改变提交以后立即改变集群的状态。->分布式数据库、分布式锁,paxo,raft,zab.MySQL主从半同步复制\Zookeeper
- 业界主要采用了 XA 协议的强一致规范以及柔性事务的最终一致规范。
BASE理论
BASE理论是对CAP中AP的一个扩展,业务系统牺牲一致性来换取系统的可用性和分区容错性。BASE是下面三个短语的缩写
- Basically Available 基本可用:通过支持局部故障而不是系统全局故障来实现的。如将用户分区在 5 个数据库服务器上,一个用户数据库的故障只影响这台特定主机那 20% 的用户,其他用户不受影响。
- Soft State 软状态,允许系统中存在中间状态,这个状态不影响系统可用性,这里指的是 CAP 中的不一致。
- Eventually Consistent 最终一致是指经过一段时间后,所有节点数据都将会达到一致。这个时间取决于网络延时、系统负载、数据复制方案设计等等因素。
为什么需要一致性算法?
- 数据不能存在单个节点(主机)上,否则可能出现单点故障;多个节点(主机)需要保证具有相同的数据
常用的一致性算法分类?
- Paxos算法:能够在存在故障节点的情况下保证系统的一致性。
- Raft算法:比Paxos算法更易于理解和实现的一致性算法,它将分布式一致性问题分解成多个易于处理的子问题。
- ZAB协议:Zookeeper中使用的一种一致性协议,它通过选举一个leader来协调多个follower之间的数据更新。
- 2PC协议:分布式系统中常用的一致性协议,它通过预提交和提交两个阶段来保证系统的一致性。
- 3PC协议:3在2PC协议的基础上增加了超时机制和准备阶段的“可以提交”状态,以提高系统的性能和可靠性。
- Gossip协议:一种基于随机化的分布式一致性协议,它通过节点之间的随机通讯来传播数据和状态信息,从而达到一致性的目的。
Paxos算法
- Paxos算法是基于消息传递且具有高效容错特性的一致性算法
- 在Paxos中有这么几个角色,一个节点可以同时充当不同角色。
- Proposer(提议者):提议者提出提案,用于投票表决。提案=编号+value,可以表示为[M,V],每个提案都有唯一编号,而且编号的大小是趋势递增的
- Accecptor(接受者):对提案进行投票,并接受达成共识的提案。
- Learner(学习者):被告知投票的结果,接受达成共识的提案。
- Proposal(提议)
- 算法流程:
- 1.准备阶段(Prepare Phase)
- 提议者Proposer提议一个编号为N(N必须大于之前本提议者所有Proposal提案的编号)的Proposal提案,然后向接受者Accecptor的某个超过半数的子集成员发送包含Proposal提案的prepare请求,由接受者Accecptor决定哪个请求占大多数
- 如果一个接受者Accecptor收到包含编号为N的Proposal的prepare请求,并且编号N大于它已经接收的所有prepare请求的编号,然后接受者会返回promise承诺,忽略任何编号小于N的Proposal提案。同时包括已经accept过的最大编号的Proposal提案作为响应反馈给提议者
- 接受者在收到提案后,会给与提议者两个承诺与一个应答:
- 两个承诺:承诺忽略提案号小于或等于N的Prepare请求;承诺忽略提案号小于N的Accept请求
- 一个应答:回复已经accept的提案中提案号最大的那个提案所设定的值NmaxValue和提案号Nmax,如果这个值从来没有被任何提案设定过,则返回空值。如果不满足已经做出的承诺,即收到的提案号并不是决策节点收到过的最大的,那允许直接对此 Prepare 请求不予理会
- 2.Accept(接受)阶段
- 如果提议者Proposer收到来自半数以上的接受者对于它发出的编号为N的prepare请求的响应,然后给Proposal提案设置值value,value就是从Accecptor接收者中收到的响应中编号最大的提案的值,如果响应中不包含任何提案,那么它可以随意选定一个值。此时,提议者Proposer会向接受者Accecptor的某个超过半数的子集成员发出已经设置值的Accept Request Message
- 如果接受者Accecptor收到这个编号为N的Proposal提案的Accept Request Message,如果这个编号N大于接受者Accecptor之前所有返回promise承诺,则接受者Accecptor就会Accept,同时向提议者Proposer和所有学习者Learner发送Accepted Message,其他情况则接受者Accecptor忽略Accept Request Message
- 注意:接受者Accecptor可以Accept多个Proposal提案,在某些失败情况下,Proposal提案可能有不同的值,但是Paxos算法保证值最终达到一致;当多个提议者Proposer发送冲突的Prepare请求,或者提议者Proposer没有接收到超过半数Promise承诺或者Accepted Message,以上这些情况都会使新一轮提议者发起编号更大的proposal; 当接收者Accecptor接收acceptAccept Requeset Message时,也会选出在提议者Proposer的leader,因此,Paxos算法也适合在集群中选出leader
- 1.准备阶段(Prepare Phase)
- Paxos算法有什么缺点吗?怎么优化?
- 上述为Basic Paxos 算法,在单提议者的前提下是没有问题的,但是假如有多个提议者互不相让,那么就可能导致整个提议的过程进入了死循环。
- Lamport 提出了 Multi Paxos 的算法思想。在多个提议者的情况下,选出一个Leader(领导者),由领导者作为唯一的提议者,这样就可以解决提议者冲突的问题。
![paxos.png)
Raft算法
- Raft算法的角色
- Leader(领导者)
- Follower(跟随者)
- Candidate(候选人)
- 领导者由跟随者投票选出。刚开始没有 领导者,所有集群中的 参与者 都是 跟随者。所有跟随者 都能参与竞选,这时所有跟随者的角色就变成了 候选人,民主投票选出领袖后就开始了这届领袖的任期Term,然后选举结束,所有除 领导者 的 候选人 又变回 跟随者 服从领导者领导。
- Leader选举过程
- Raft 使用心跳(heartbeat)触发Leader选举。当Server启动时,初始化为Follower。Leader向所有Followers周期性发送heartbeat。如果Follower在选举超时时间内没有收到Leader的heartbeat,就会等待一段随机的时间后发起一次Leader选举。Follower将其当前term加一然后转换为Candidate。它首先给自己投票并且给集群中的其他服务器发送 RequestVote RPC 。结果有以下三种情况:
- 赢得了多数(超过1/2)的选票,成功选举为Leader;
- 收到了Leader的消息,表示有其它服务器已经抢先当选了Leader;
- 没有Server赢得多数的选票,Leader选举失败,等待选举时间超时(Election Timeout)后发起下一次选举。
- 选出 Leader 后,Leader 通过 定期 向所有 Follower 发送 心跳信息 维持其统治。若 Follower 一段时间未收到 Leader 的 心跳,则认为 Leader 可能已经挂了,然后再次发起 选举 过程。
总结
本文介绍了的使用,如有问题欢迎私信和评论