我们不仅要在平时⼯作和学习中，认真、全⾯的学习理论，掌握概念的内涵，还要能“包容”和“发展”着理解技术。
红外线烘干
随着分布式的发展，对应的算法也在不断的演进。这⾥是学习了极客时间的⼀个专栏中，从中总结的关于ZAB协议与Raft协议之间的⼀个⽐较笔记总结。
ZAB 是通过“⼀切以领导者为准”的强领导者模型和严格按照顺序处理、提交提案，来实现操作的顺序性的。主节点是基于 TCP 协议来⼴播消息的，并保证了消息接收的顺序性。出来的⽐较早。 Raft协议是Raft协议就是⼀切以领导者为准的⽅式，实现⼀系列值的共识和各节点⽇志的⼀致性。通过⽇志的连续性来保证消息或者说是数据的顺序性以及完整性。Raft协议中⽇志不仅是数据的载体，同时，⽇志的完整性还会影响领导者选举的结果（注：选举的因素不仅仅只有⽇志的完整性来保证，还有任期等其他因素）。 Raft⽬前是⼯程上使⽤较为⼴泛的强⼀致性、去中⼼化、⾼可⽤的分布式协议。在这⾥强调了是在⼯程上，因为在学术理论界，最耀眼的还是⼤名⿍⿍的Paxos。如果想深⼊了解可以阅读：
Raft是作为共识算法和 Multi-Paxos 算法提出的。当它被⼴泛接受和认可后，共识算法的内涵也就丰富
和发展了，不仅能实现⼀系列值的共识，还能保证值的顺序性。同样，Multi-Paxos 算法不仅指代多次执⾏ Basic Paxos 的算法，还指代主备、强领导者模型的共识算法。
从上⾯我们可以看出Raft 算法和 ZAB 协议很类似，⽐如主备模式（也就是领导者、跟随者模型）、⽇志必须是连续的、以领导者的⽇志为准来实现⽇志⼀致等等。有点像“英雄所见略同”。
同时也在ZAB协议的基础上做了⼀些改进（Raft协议⽐ZAB协议出来的晚），⽐如 ZAB 协议要实现操作的顺序性，⽽ Raft 的设计⽬标，不仅仅是操作的顺序性，⽽是线性⼀致性，这两个⽬标，都决定了它们不能允许⽇志不连续，要按照顺序提交⽇志，那么，它们就要通过上⾯的⽅法实现⽇志的顺序性，并保证达成共识（也就是提交）后的⽇志不会再改变。
这⾥我们就ZAB 和 Raft 做个对⽐，来具体说说 ZAB 和 Raft 的异同。既然我们要做对⽐，那么⾸先要定义对⽐标准，我是这么考虑的：你应该有这样的体会，同⼀个功能，不同的同学实现的代码都会不⼀样（⽐如数据结构、代码逻辑），所以过于细节的⽐较，尤其是偏系统实现⽅⾯的，意义不⼤（⽐如跟随者是否转发写请求到领导者，不仅意义不⼤，⽽且这是 ZAB 和 Raft 都没有约定的，是集系统需要考虑的）。
我们可以从核⼼原理上做对⽐：
领导者选举：
ZAB 采⽤的“见贤思齐、相互推荐”的快速领导者选举（Fast Leader Election），节点间通过PK竞争（资本是所持有的信息）看哪个节点更适合做Leader，⼀个节点PK后，会将选票信息⼴播出去，最终选举出了⼤多数节点中数据最完整的节点。
Raft 采⽤的是“⼀张选票、先到先得”的⾃定义算法（注：⾥⾯包含了⼀个随机等待时间的概念，来保证最多⼏次选举就能完整选举过程。），这⾥简单说⼀下就是⼀个节点发现leader挂了，就选举⾃⼰为leader，然后通知其他节点，其他节点把选票投给第⼀个通知它的节点。（注：这⾥其实也会涉及到PK，根据数据的完整性以及任期等信息，如果通知它的节点 没有当前节点的数据完整等那么 当前节点是不会将选票投给该节点，这⼀块概念很多，建议看之前上⾯的博客⽂章）
以上看来，Raft 的领导者选举，需要通讯的消息数更少，选举也更快。
视频硬件
⽇志复制：
Raft 和 ZAB 相同，都是以领导者的⽇志为准来实现⽇志⼀致，⽽且⽇志必须是连续的，也必须按照顺序提交。
ZAB通过TCP来保证操作的顺序性。
Raft协议通过Log Entry 加⾃⼰的校验来实现⽇志的连续性。建议看上⾯的博客⽂章
电玉粉
读操作和⼀致性：
ZAB 的设计⽬标是操作的顺序性，在 ZooKeeper 中默认实现的是最终⼀致性，读操作可以在任何节点上执⾏；（注：很多地⽅说ZK是CP 这没有⽑病，但是并不是指ZK中的读写时强⼀致性，是指在发⽣P的时候，ZK是C，或者看到这个很懵，看下上⾯的博客，以及仔细看下CAP理论的图，⾥⾯也清晰的标记着在没发⽣P的时候，AC是可以共存的）
⽽ Raft 的设计⽬标是强⼀致性（也就是线性⼀致性），所以 Raft 更灵活（可以⾃⼰配置），Raft 系统既可以提供强⼀致性，也可以提供最终⼀致性，但是⼀般为了保证性能，默认提供的也是最终⼀致性。
写操作：
Raft 和 ZAB 相同，写操作都必须在领导者节点上处理。
成员变更：
Raft 和 ZAB 都⽀持成员变更，其中 ZAB 以动态配置（dynamic configuration）的⽅式实现的。那么当你在节点变更时，不需要重启机器，集是⼀直运⾏的，服务也不会中断。
真空抽气机组其他：
纠偏机
相⽐ ZAB，Raft 的设计更为简洁，⽐如 Raft 没有引⼊类似 ZAB 的成员发现和数据同步阶段，⽽是当节点发起选举时，递增任期编号，在选举结束后，⼴播⼼跳，直接建⽴领导者关系，然后向各节点同步⽇志，来实现数据副本的⼀致性。
网篮法ZAB协议的数据同步的阶段，ZAB集式⽆法对外提供服务。
其实，ZAB 的成员发现，可以和领导者选举合到⼀起，类似 Raft，在领导者选举结束后，直接建⽴领导者关系，⽽不是再引⼊⼀个新的阶段；数据同步阶段，是⼀个冗余的设计，可以去除的，因为 ZAB 不是必须要先实现数据副本的⼀致性，才可以处理写请求，⽽且这个设计是没有额外的意义和价值的。
还有，ZAB 和 ZooKeeper 强耦合，你⽆法在实际系统中独⽴使⽤；⽽ Raft 的实现（⽐如 Hashicorp Raft）是可以独⽴使⽤的，编程友好。
1024这⼀天，今天很忙，但是在晚上的时候，我写这下这篇质量不⾼的⽂章，主要是刚好对Raft协议以及ZAB协议的学习做⼀个消息的总结，也是给⾃⼰⽴下⼀个flag，让明年的⾃⼰能想起2020.10.24这⼀天，让⾃⼰⼀直记住下⾯这句话：
天⾏健，君⼦以⾃强不息；地势坤，君⼦以厚德载物
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议