分布式架构系统理论

分布式架构系统理论

目录

• 分布式一致性和CAP理论
• 分布式一致性算法
  • RAFT
  • NWR&Gossip
• 拜占庭将军问题
• 分布式环境中的脑裂和Lease

1.分布式一致性和CAP理论

一致性： 在分布式系统中有很多的数据备份，在同一时刻，所有备份当中的同一份数据，他的值都是一样的，也就是说你从任意备份中获取同一个数据，他的值都是一样的。
可用性： 在分布式系统中，可用性是指集群中，有任何一部分节点出现故障无法访问的时候，那你集群当中剩下的节点依然可以去继续提供服务。
分区容错性： 指的是分布式系统当中的这些节点，在经过一定时间内，仍然无法达到数据一致性，那就意味着集群当中发生了分区的情况，就像是脑裂一样，一分为二。在这样的情况下，我们就必须在前面提出的一致性和可用性，这两者之间做一个二选一的选择。
关于三选二问题这个大佬讲的通俗易懂一文理解分布式常见的一致性算法，我也摘抄一点，加深一点印象，但我感觉三选二应该是CP或者AP没有CA

CAP指出，一个分布式系统只能满足三项中的两项而不可能满足全部三项。举例来看：如下图所示，假设有五个节点：n1~n5，因网络分区故障被分为两组：【n1，n2】和【n3，n4，n5】，那么当处理客户端请求时（为了支持“分区容错性”，即支持P）：

1. 如果要保证C（一致性），那么它需要把消息复制到所有节点，但是网络分区导致无法成功复制到n3~n5，所以他只能返回“处理失败”的结果给客户端。（这时系统就处在不可用状态，即丧失了A）
2. 如果要保证可用性A，那么n1就只能把消息复制到n2，而不用复制到n3~n5（或者无视复制失败/超时），但n3同时也只可能再处理客户端请求，n3也为了保证A而做出了同样的处理。那么【n1，n2】和【n3 ~n5】的状态就不一致了，于是就丧失了C（一致性）
3. 如果不能容忍网络分区，则P（分区容错性）不能满足

我们可以看这个例子，如下是一个主节点下面连接两个子节点，节点1下面挂着服务集群123，节点2下面同样的也挂了一堆服务集群。这幅图是一幅理想情况的分布式系统架构，我们集群从任意节点下面可以读取到相同的数据，因此我们集群之间可以互相调用。

如果主节点与从节点的连接断了，而左边的一个服务集群失效了，那他就不能将他的失效性息发给主节点，也不能同步给节点2，这种情况下，服务集群与服务集群间的访问可能失败。这也就说明了一致性在分布式系统架构的重要性。

2. 分布式一致性算法Raft

Raft算法当中定义了三个角色，如下图所示

• Leader：负责日志写入，和日志复制
• Follower： 担任选民的角色，为候选者投票，谁先给他发消息，他就投给谁
• Candidate： 通过选举投票成为一个Leader

2.1选举过程

1. 初始情况，大家都是Follower，每人手中有一票

2. 第一个Follower想当Leader，变为Candidate，向Follower发送信息寻求选票，票数过半，成为Leader

3. 如果第四个Follower挂了，不能投票了，那该怎么办呢？Candidate收不到第四个Follower的选票，机器总数量定格在4台。这时Candidate可以自投

4. 又到了岁月静好的时候
   

5. 突然有一天，Leader挂掉了。理想情况下，如图所示
   真实情况却是多个Follower想要当Leader，出现多个Candidate，如图
   某些极端情况下（再上图再加一个Follower）两个Candidate加上自投也只能各拿到2票，这时，这个算法还有一轮加时赛，在加时赛中，再次打平的几率微乎其微，每个Follower他只能有一票投出，谁先让他投票他投给谁，基于这个机制，两次比赛都拿到相同的票数的概率非常非常小，票数高者成为Leader，票数低的退回Follower角色当中来

6. 选举结束，新Leader开始日志写入
   

7. 某一天，那个挂掉的Leader突然又上线了，并且他还带了一个小迷弟。这就产生一个类似脑裂的现象。这就好比由于网络通信故障一部分分区与Leader失连，leader会继续向他当前可以访问到的选举节点来发送日志写入的指令，而网络中另一个分区将重新选举一个leader，有一天网络修复好了，那有两个leader该怎么办呢？其中会有一个版本更老的leader退居二线，那么他曾经写下的指令通通回滚掉，并且从一个Leader角色变为Follower角色，并且向新的Leader报道。

3. 共识算法–拜占庭将军问题

拜占庭将军问题提供了对分布式共识算法的一种情景化描述，这里提供两种拜占庭将军问题的算法（参考小毛开锁王大佬）：

• 口信消息型解决方案（a solution with oral message）
• 签名消息型解决方案（a solution with signed message）

拜占庭将军问题是分布式系统领域最复杂的容错模型，他描述了如何在存在恶意行为（如消息篡改或伪造）的情况下使分布式系统达成一致，是我们理解分布式一致性协议和算法的重要基础。

3.1拜占庭将军的描述

拜占庭帝国军队的几个师驻扎在地城外，每个师都由各自的将军指挥，将军们只能通过信使相互沟通，在观察敌情后，他们必须制定一个共同的行动计划，如进攻（Attack）或者撤退（Retreat），且只有当半数以上的将军共同发起进攻时才能获取胜利，然而，其中的一些将军可能是叛徒，试图阻止忠诚的将军达成一致的行动计划。更糟糕的是，负责消息传递的信使也可能是叛徒，他们可能篡改或伪造信息，也可能使得消息丢失。
为了深入理解拜占庭将军问题，我们以三将军问题为例进行说明

• 当三个将军都忠诚时，如图
  
  将军们经过投票表决的结果为进攻：撤退=2：1，所以将一同发起进攻取得胜利。对于三个将军，每个将军都能执行两种决策（进攻或撤退）的情况下，共存在6种不同的场景，上图是其中的一种，对于其他的情况可简单的推理，通过投票三个将军都将达成一致的行动计划。
• 当三个将军存在一个叛徒时，将可能扰乱正常地作战计划，如图所示
  
  图中展示了叛徒A为叛徒地场景，他给B发送进攻命令，给C发送苟着命令，导致B通过投票得到进攻：苟着=2：1，将发起进攻，而B经过投票得出苟着：进攻=2：1，将继续苟着，最后只有B一个人发起进攻并战败。
  事实上，对于三个将军存在一个叛徒地想要总能达到一致的行动方案是不可能的，如果存在m个叛徒，那么至少需要3m+1个将军，才能最终达到一致的行动方案。

3.2 拜占庭问题解决办法

3.2.1 口信消息型解决方案

首先，对于口信消息的定义如下：

• A1. 任何已经发送的消息都将被正确的传达；
• A2.消息的接收者知道是谁发送了消息；
• A3.消息的缺席可以被检测
  基于口信消息的定义，我们可以知道，口信消息不能被篡改但是可以被伪造，基于对上图的推导，我们知道存在一个叛徒时，必须再增加3个忠将才能达到最终的行动一致，为加深理解，我们利用3
  个忠将1个叛徒的场景对口信消息型解决方案进行推导。在口信消息型解决方案中，首先发送消息的将军称为指挥官，其余将军称为副官，对于3忠1叛的场景需要进行两轮（m+1）作战信息协商，如果没有收到作战信息那么默认撤退。

1. 下图是指挥官为忠将的场景
   在第一轮作战协商中，指挥官向ABC三为副将发送进攻指令，第二轮作战协商中，B与C根据指挥官的指令各向其他副官发送进攻指令，而A叛徒为了绕乱作战发送苟着命令,BC根据投票结果发起进攻且取得成功。
2. 下图时指挥官为叛将的场景，
   在第一轮作战协商中，指挥官向BC发送进攻指令，对A发送苟着命令，第二轮作战协商，各副官最终还是能达到一直进攻的计划。

如上所述，对于口信消息型拜占庭将军问题，如果叛将人数为m，将军人数不少于3m+1，那么最终能达成一致的行动计划。值得注意的是，这个算法中，叛将人数m是已知的，且叛将人数决定了递归的次数，即叛将数m决定了进行作战协商的轮数，如果存在m个叛将，则需要进行m+1轮作战信息协商。这也是上述存在一个叛将时需要进行两轮作战协商的原因。

3.2.2签名消息型解决方案

同样，对签名消息的定义是在口信消息定义的基础上增加了两条：

• A4： 忠诚将军的签名违法伪造，而且对他签名消息的内容进行任何更改都会被发现；
• A5：任何人都能验证将军签名的真伪

基于签名消息的定义，我们可以知道，签名消息无法被伪造或者篡改，为了深入理解签名消息型解决方法，我们同样以三将军问题为例进行推导。

1. 下图是忠臣率先发起作战协商的场景，
   忠诚率先向BC发起进攻命令，一旦C篡改了A的消息，B将发现作战信息被C篡改，B将执行A发送的命令。
2. 下图是叛徒率先发起作战协商的场景
   
   叛将A率先发送了误导信息，BC将发现A发送的作战信息不一致，因此断定其为叛将，可对其处理后在进行作战信息协商。

签名消息型解决方法可以解决任何数量叛将的情况。
大佬的总结：

4.脑裂与Lease

1. 初始情况，由Leader向Follower进行日志写入
   
2. 某一天由于网络故障导致右边三台服务器与Leader失联，一分为二，经过一段时间后，一个Follower重新选举成为Leader3.
3. 由两个集群的数据可能不一致，一个Client可以从不同的集群读取不同的数据，这种现象我们就称之为脑裂，
4. 那我们怎么解决这种问题呢？

• 全局过半解决方案
  
  当前全局机器数量N为5，也就是说票数>=3才能当选为Leader，如上图，左边的leader退化成为Follower，右边新选举一个Leader。由>=3我们可以看出，集群中可容忍最大失效机器数量为2
• Lease机制解决方案
  Lease他是一个契约，就像是一个认主契约一样，在一个期间内，认定你是我的主人。
  他是颁发者发给某个节点的身份的象征。他有如下特点：
  
  下图表示10s颁给一个Lease，若Leader在Lease在租约0.05期间挂掉了，整个集群牺牲一定的可用性，等待5s过期，重新颁布Leader，确保数据一致性。**注意可能出现颁发Lease的机器与接收这个租约的机器之间的时钟不匹配，这就叫时钟误差，即使只有短暂的1s也可能导致集群的不可用。**一般Lease的时间设置为10s或10的倍数，以免等待时间太久。
  、

5 总结

参考资料

慕课网架构师课
https://blog.csdn.net/wypblog/article/details/114505286
https://zhuanlan.zhihu.com/p/107439021