Cover_sky的博客

比如日志同步，保证各个节点的日志一致性，选主的唯一性。ACID一致性使有关数据库规则，如果数据表结构定义一个字段值是唯一的，那么一致性系统将解决所有操作中导致这个字段值非唯一的情况，如果带有一个外键的一行记录被删除，那么其外键相关记录也应该被删除，这就是ACID一致性的意思。CAP理论的一致性是保证同样一个数据在所有不同服务器上的拷贝i都是相同的，这是一种逻辑保证，而不是物理，因为光速限制，在不同服务器上这种复制是需要时间的，集群通过阻止客户端查看不同节点上还未同步的数据维持逻辑视图。

一种说法是ZooKeeper是最终一致性，因为由于多副本、以及保证大多数成功的ZAB协议，当一个客户端进程写入一个新值，另外一个客户端进程不能保证马上就能读到这个值，但是能保证最终能读取到这个值。另外一种说法是ZooKeeper的ZAB协议类似于Paxos，提供了强一致性。但这两种说法都不准确，ZooKeeper文档中明确写明它的一致性是Sequential Consitency即顺序一致。

如买最后一张车票，两个售票处分别通过某种方式确认过这张票的存在。这时，两家售票处几乎同时分别来了一个乘客要买这张票，从各自"观察"看来，自己一方的乘客都是先到的，这种情况下，怎么能达成对结果的共识呢？看起来很容易，卖给物理时间上率先提交请求的乘客即可。然而，对于两个来自不同位置的请求来说，要判断在时间上的"先后"关系并不是那么容易。两个车站的时钟时刻可能是不一致的。时钟计时可能不精确的。根据相对论的观点，不同空间位置的时间是不一致的。因此追求绝对时间戳的方案是不可行的，能做的是要对事件的发生进行排序。

etcd是线性一致性读，而zk却是顺序一致性读，再加上各种共识、强弱一致的名词，看到欸度时候总会混淆，这里会给出一些例子来帮助理解。在谈到一致性这个词时，你会想到CAP理论的consistency,或者ACID钟的consistency,或者cache一致性协议的coherence，还是Raft/Paxos钟的consensus?一致性这个词在不同的领域具有不同的含义，毕竟这个中文词在英文词对应了不同的术语，consistency，coherence，consensus三个单词统一翻译为"一致性"。

线性一致性(Linearizability),也称为原子性或强一致性，是分布式系统中的一个一致性模型，它定义了系统对读写操作的行为，以确保系统表现得好像只有一个数据副本，并且所有操作都是原子的。线性一致性模型是分布式系统中一致性最强的一个模型，它为客户端提供了最直观和最易于理解的行为保证。然而，实现线性一致性通常需要牺牲性能和可用性，因为在保持强一致行的同时，系统需要在多个副本之间进行更多的协调和通信。线性一致性模型在需要严格数据一致性的场景张非常重要，例如金融系统、实时控制系统等。

1.在比特币的区块链中，PoW算法是通过SHA256哈希运算计算出符合指定条件的哈希值来证明工作量的。2.51%攻击的本质是因为比特币的区块链约定了"最长链胜出，其他节点在这条链上扩展"，所以攻击者可以通过优势算力实现对最长链的争夺。3.除了通过PoW算法增加坏人作恶的成本，比特币还通过"挖矿得币"奖励好人，最终保持了整个系统的稳定运行。另外，因为拜占庭容错算法(比如PoW算法、PBFT算法)能容忍一定比例的作恶行为，所以它在相对开放的场景中应用广泛，比如公链、联盟链。

1.PBFT算法是通过签名(或消息认证码MAC)来约束恶意节点的行为，同时采用三阶段协议，基于大多数原则达成共识的。另外，与口信消息型拜占庭问题之解(以及签名消息型拜占庭问题之解)不同的是，PBFT算法实现的是一系列值得共识，而不是单值的共识。2.客户端通过等待f+1个相同响应消息超时来发现主节点可能在作恶，此时客户端会发送客户端请求给所有集群节点，从而触发可能的视图变更。与Raft算法在领导者期间服务不可用类似，在视图变更时，PBFT集群也是无法提供服务的。

前面提到了拜占庭将军问题之后，有人可能会感到困惑:口信消息型拜占庭问题直接在实际项目中是如何落地的呢？事实上，它很难在实际项目中落地，因为口信消息型拜占庭问题之解是一个非常理论化的算法，没有与实际场景结合，也没有考虑如何在实际场景中落地和实现。比如，它实现的是在拜占庭错误场景下，忠将们如何在判断干扰时就一致行动达成共识。但是它并不关心结果是什么，这会出现一种情况:现在适合进攻，但将军们达成的最终共识却是撤退。很显然，这不是我们想要的结果。

前面已经在CAP理论介绍了TCC，这里只想补充一点:可以对比二阶段提交协议来理解TCC包含的预留(Try)、确认(Confirm0或撤销(Cancel)这两个阶段，分析如下。1.预留和二阶段提交协议中的提交请求阶段的操作类似，具体是指系统会将需要确认的资源预留、锁定，确保确认操作一定能执行成功。2.确认和二阶段提交协议中的提交执行阶段的操作类似，具体是指系统将最终执行的操作3.撤销比较像二阶段提交协议中的回滚操作，具体是指系统将撤销之前预留的资源，也就是撤销已执行的预留操作对系统产生的影响。

提到XA规范，就不得不说DTP(Distributed Transaction Processing, 分布式事务处理)模型，因为XA规范约定的是DTP模型中的两个模块(事务管理其和资源管理器)的通信方式，如图所示。为了更好地理解DTP模型,我来解释下DTP各模块的作用。1.AP:应用程序(Application Program)，一般是指事务的发起者(比如数据库客户端或者访问数据库的程序)，定义事务对应的操作(比如更新操作。

1.一般而言，不推荐副本数超过当前的节点数，因为当副本数超过节点数时，就会出现同一个节点存在多个副本的情况。当这个节点有故障时，上面的多个副本就都会收到影响2.当W+R>N时，可以实现强一致性。另外，如何设置N、W、R值，取决于我们想优化哪方面的性能。比如,N决定了副本的冗余备份能力；如果设置W=N,则读性能较好;如果设置R=N，则写性能比较好；如果设置W=(N+1)/2、 R=(N+1)/2，则容错能力比较好，能容忍少数节点[也就是(N-1)/2]的故障。

1.Gossip协议作为一种异步修复、实现最终一致性的协议，反熵再存储组件中应用广泛，比如Dynamo、InfluxDB、Cassandra，在需要实现最终一致性的实际工作场景中，优先考虑反熵2.因为谣言传播具有传染性，如一个节点传给了另一个节点，另一个节点又将充当传播者，传给其他节点，所以非常适合动态比那花的分布式系统，比如Cassandra。

1.ZAB协议是通过"一切以领导者为准"的强领导者模型和严格按照顺序处理、提交提案来实现操作的顺序性的2.领导者选举的目标是选举出大多数节点中数据最完整的节点，也就是大多数节点中事务标识符值最大的节点。任期编号、事务标识符、集群ID的值的大小决定了哪个节点更适合作为领导者，按照顺序，值最大的节点更适合作为领导者3.数据同步是通过以领导者的数据为准的方式来实现各节点数据副本的一致性的。需要注意的是，基于"大多数"的提交原则和选举原则能确保被复制到大多数节点并提交的提案不再改变。

你应该有这样的体会，如果你想了解一个网络服务，执行的第一个功能肯定是写操作，然后才会执行读操作。比如，你要了解ZooKeeper，那么肯定会在zkClient.sh命令行中执行写操作(比如create /geekbang 123)写入数据，然后再执行读操作(比如get /geekbang)查询数据。这样一来，你才会直观地理解ZooKeeper的使用方法。

成员发现是通过跟随者和领导者交互来完成的，目标是确保大多数节点对领导者的关系没有异议，也就是确立领导者的领导地位。成员发现的实现流程如图所示。1.2 领导者会调用Leader.lead()函数，并设置ZAB状态为成员发现状态，如代码所示这样，ZooKeeper就实现了成员发现，且各节点就领导者的领导关系达成了共识。当跟随者和领导者设置ZAB状态为数据同步状态后，它们就进入了数据同步阶段。那么ZooKeeper中的数据同步是如何实现的呢？

如果我们想把ZAB集群恢复到正常状态，那么新领导者就必须确立自己的领导关系，成为唯一有效的领导者，然后作为主节点"领导"各备份节点一起处理读写请求。

首先我们来看看ZooKeeper是如何实现成员身份的？在ZooKeeper中，成员状态是在QuorumPeer.java中实现的，为枚举型变量其实，ZooKeeper没有直接定义成员身份，而是用了对应的成员状态来表示，比如，处于FOLLOWING状态的节点为跟随者。如果你想研究相关成员的功能和实现，那么可以把对应的成员状态作为切入点来研究。比如，你想研究领导者的功能实现，可以在代码中搜索LEADING关键字，然后研究相应的上下文逻辑，进而得到自己想要的答案。

众所周知，系统在运行中不可避免会出现各种各样的问题，比如进程崩溃了、服务器死机了，这些问题会导致很严重的后果，让系统没办法继续运行。在ZAB协议中，写请求是必须在主节点上处理的，而且提案的广播和提交也是由主节点来完成的。既然主节点那么重要，如果它突然崩溃(宕机)了，该怎么办呢？答案是选举出新的领导者(也就是新的主节点)。在我看来，领导者选举关乎节点故障容错能力和集群可用性，是ZAB协议非常核心的设计之一。想象一下，如果没有领导者选举，主节点故障了，那么整个集群将无法写入，这将是极其严重的灾难性故障。

如果用一句话解释ZAB协议到底是什么，我觉得它是能保证操作顺序性的、基于主备模式的原子广播协议。接下来，还是以指令X、Y为例具体演示一下，帮助你更好地理解为什么ZAB协议能实现操作的顺序性(为了演示，我们假设节点A为主节点，节点B、C为备份节点)。首先，在ZAB协议中，写操作必须在主节点(比如节点A)上执行。如果客户端访问的节点是备份节点(比如节点B),则备份节点会将写请求转发给主节点，如图所示。

很多人应该都使用过ZooKeeper， 它是一个开源的分布式协调服务，比如你可以用它进行配置管理、名字服务等。在ZooKeeper中，数据是以节点的形式存储的。我们分别创建了配置节点/geekbang和/geekbang/time,对应的值分别为123和456.那么在这里提个问题:你觉得在ZooKeeper中能用兰伯特的Multi-Paxos实现各节点数据的公式一致吗？当然不行。

1.一致哈希算法是一种特殊的哈希算法，该算法可以使节点增减变化时只影响到部分数据的路由寻址，也就是说我们只要迁移部分数据，就能实现集群的稳定了。2.当节点数较少时，可能会出现节点在哈希环上分布不均匀的情况，即每个节点实际在环上占据的区间大小不一，最终导致业务对节点的访问冷热不均，而这个问题可以通过引入更多的虚拟节点来解决。3.一致哈希算法本质上是一种路由寻址算法，适合简单的路由寻址场景，比如，在KV存储系统内部，它的特点是简单，不需要维护路由信息。

通过哈希算法，每个key都可以寻址到对应的服务器，比如，查询key是key-01,计算公式为hash(key-01)%3,警告过计算寻址到了编号为1的服务器节点A，如图所示。但如果服务器数量发生变化，我们基于新的服务器数量来执行哈希算法时，就会出现路由寻址失败的秦广，导致Proxy无法找到之前寻址到的那个服务器节点，这是为什么呢？想象以下，加入3个节点不能满足当前的业务虚要，这时我们增加了一个节点，节点数量从3变为4，那么之前的hash(key-01)%3=1就变成了。

在了解了Raft算法的特点、领导者选举、什么是日志、如何复制日志以及如何处理不一致日志，还有成员变更的问题和单节点变更的方法等。1.本质上，Raft算法以领导者为中心，选举出的领导者以"一切以我为准"的方式，达成值的共识和实现各节点日志的一直。2.在Raft算法中，副本数据是以日志的形式存在的，其中日志项中的指令表示用户指定的数据。在Raft算法中日志必须是连续的，而兰伯特的Multi-Paxos不要求日志是连续的，而且在Raft算法中，日志不仅是数据的载体，日志的完整性还影响着领导者选举的结果。

在日常工作中，你可能会遇到服务器故障的情况，这时你需要替换集群中的服务器。如果遇到需要改变数据副本数的情况，则需要增加或移除集群中的服务器。总的来说，在日常工作中，集群中的服务器数量是会发生变化的。也许你会问，Raft算法是共识算法，它对集群成员进行变更时(比如增加2台服务器)，会不会因为集群分裂出现两个领导者呢？

你可以把Raft算法的日志复制理解成一个优化后的二阶段提交(将二阶段优化成了一阶段)。优化后减少了一半的往返消息，也就是降低了一半的消息延迟，那日志复制的具体过程又是什么呢？首先，领导者进入第一阶段，通过日志复制RPC消息将日志项复制到集群中的其他节点上。接着如果领导者接收到大多数的"复制成功"响应后，它会将日志项应用到它的状态机，并返回成功给客户端。如果领导者没有接收到大多数的"复制成功"响应，那么就返回错误给客户端。

我们知道，议会选举中的领导者是有任期的，当领导者任命到期后，需要重新再次选举。Raft算法中的领导者也是有任期，每个任期由单调递增的数字(任期编号)标识。比如，节点A的任期编号是1。任期编号会随着选举的举行而变化，分析如下。与现实议会选举中的领导者的任期不同，Raft算法中的任期不只是指时间段，而且任期编号的大小会影响领导者选举和请求的处理。

Raft算法属于Multi-Paxos算法，它在兰伯特Multi-Paxos思想的基础上做了一些简化和限制，比如日志必须是连续的，只支持领导者(Leader)、跟随者(Follwer)和候选人(Candidate)3种状态。在理解和算法实现上，Raft算法相对容易许多。除此之外，Raft算法是现在分布式系统首选的共识算法。绝大多数选用Paxos算法的系统(比如Chubby、Spanner)都是在Raft算法发布前开发的，当时没有其他选择;

我们可以通过引入领导者(Leader)节点来解决第一个问题。也就是说将领导者节点作为唯一提议者，如图所示。这样就不存在多个提议者同时提交提案的情况，也就不存在提案冲突的情况了。这里补充一点:在论文中，兰伯特没有说如何选举领导者，需要我们在实现Multi-Paxos算法的时候自己实现。比如Chubby中的主节点(也就是领导者节点)是通过执行Basic Paxos算法进行投票选举产生的，那么如何解决第二个问题，也就是如何优化Basic Paxos执行呢。

想象这样一个场景，某地出现突发事件，当地村委会、负责人等在积极研究和搜集解决该事件的解决方案，你也决定参与其中，提交提案，建议一些解决方法。为了和其他村民的提案做区分，你的提案还得包含一个提案编号，以起到唯一标识的作用。与你的做法类似，在Basic Paxos中，兰伯特也使用提案代表一个提议。不过提案中除了包含提案编号，还包含提议值。为了方便表示，使用[n,v]表示一个提案，其中n为提案编号，v为提议值。

提到分布式算法，就不得不提Paxos算法，在过去几十年里，它基本上时分布式共识的代名词，当前最常用的一批共识算法都是基于它改进的。比如， Fast Paxos算法、Cheap Paxos算法、Raft算法等。但是，很多人都会在准确和系统理解Paxos算法上踩坑，比如，只知道它可以用来达成共识，却不知道它是如何达成共识的。这其实从侧面说明了Paxos算法有一定的难度，可分布式算法本身就很复杂，Paxos算法自然也不会例外。当然，除了这一点，还与Paxos算法的提出者莱斯利兰伯特有关。

很多人可能喜欢使用事务型的分布式系统或者强一致性的分布式系统，因为方便，不需要考虑太多，就像单机系统一样。但是学了CAP理论后，你肯定知道在分布式系统中，要实现强一致性，必然会影响可用性。比如，在采用两阶段提交协议的集群系统中，要执行提交操作，需要所有节点确认和投票。所以，集群的可用性时每个节点可用性的乘积，比如，假设有一个拥有3个节点的集群，每个节点的可用性为99.9%，那么整个集群的可用性为99.7%，也就是说，每个月约宕机129.6分钟(按30天/月算)，这是非常严重的问题。

提到ACID,它很容易理解，在单机上实现也不难，比如可以通过锁、时间序列等机制保障操作的顺序执行，让系统实现ACID特性。但是一说要实现分布式系统的ACID特性比较难实现呢？ACID理论是对事务特性的抽象和总结，方便我们实现事务。可以这样理解：如果实现了操作的ACID特性，那么旧实现了事务。二大多数人觉得比较难，是因为分布式系统涉及多个节点间的操作。加锁、时间序列等机制只能保证单个节点上操作的ACID特性，无法保证节点间操作的ACID特性。那么怎么做才会让实现不那么难呢？

CAP不可能三角是指对于一个分布式系统而言，一致性、可用性、分区容错性指标不可兼得，只能从中选择两个，如图所示。CAP不可能三角最初是埃里克·布鲁尔(Eric Brewer)基于自己的工程实践提出的一个猜想，后被塞斯·吉尔伯特(Seth Gilbert)和南希·林奇(Nancy Lynch)证明，(https://dl.acm.org/citation.cfm?id=564601)基于证明的严谨性的考虑，塞斯吉尔伯特和南希林奇对指标的含义做了预设和限制，比如，将一致性限制为原子一致性。

在开发分布式系统的时候，会遇到一个非常棘手的问题，那就是如何根据业务特点，为系统设计合适的分区容错一致性模型，以实现集群能力。这个问题棘手在当发生分区错误时，应该如何保障系统稳定运行而不影响业务。CAP理论对分布式系统的特性做了高度抽象，比如抽象成一致性、可用性、分区容错性，并对特性间的冲突(也就是CAP不可能三角)做了总结。问题来了:什么是一致性、可用性和分区容错性？它们之间有什么关系？我们又该如何使用CAP理论来思考和设计分区容错一致性模型呢？

CFT算法解决的是分布式系统中存在故障，但不存在恶意节点的场景下的共识问题。也就是说，这个场景可能会丢失消息或者有消息重复，但不存在错误消息或者伪造消息的情况，常见的CFT算法有Paxos算法、Raft算法、ZAB协议。需要注意的是，拜占庭将军问题描述的是最困难，也是最复杂的一种分布式故障场景，该场景除了存在故障行为，还存在恶意行为。在存在恶意行为的场景中(比如在数字货币的区块链技术中)，我们必须使用拜占庭容错算法还有PBFT算法、POW算法。反之则推荐使用拜占庭容错算法，例如区块链中使用Pow算法。

签名消息是指带有数字签名的消息。数字签名与在纸质合同上进行签名来确认合同内容和证明身份类似。它既可以证实内容的完整性，又可以确认内容的来源，实现不可抵赖性(Non-Repudiation)。既然数字签名的优点那么多，那么如何实现签名消息呢?今天Bob要给Alice发送一条消息，告诉她，“我已经到北京了”。但是Bob希望这个消息能被Alice完整地接收到，即内容不能被篡改或者伪造。下面我们一起来看看如何帮Bob和Alice想想办法，看看如何发送这条消息。

这个解决办法其实是在兰伯特在论文"The Byzantine Generals Problem"中提到的口信问题型拜占庭问题之解(A Solution with Oral Message):如果叛将认数位m,将军任务不能少于3m+1,那么拜占庭将军问题就能解决了，不过，作者在论文中没有讲清除一些细节:这个算法有个前提，也就是叛将认数m,或者说能容忍的叛将数m是已知晓的。在这个算法中，叛将数m决定了递归循环的次数(也就是说，叛将数m决定了将军们要在多少轮作战信息协商)，既m+1轮(例如这里只有楚是叛