java面试-分布式理论(上)

---

什么是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
• 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 可能已经挂了，然后再次发起 选举 过程。

---

总结

本文介绍了的使用，如有问题欢迎私信和评论