常见分布式协议和算法的说明和对比( 三 ) _算法

另一个是 Multi-Paxos 思想，描述的是执行多个 Basic Paxos 实例就一系列值达成共识。Basic Paxos 是 Multi-Paxos 思想的核心。

Raft【强一致性】Raft 算法是 Paxos 算法的一种简化实现，其实 Raft 不是一致性算法而是共识算法，是一个 Multi-Paxos 算法，实现的是如何就一系列值达成共识。Raft 算法是在兰伯特 Multi-Paxos 思想的基础上，做了一些简化和限制，比如增加了日志必须是连续的，只支持领导者、跟随者和候选人三种状态，在理解和算法实现上都相对容易许多。
ZAB【最终一致性】ZAB 协议和 ZooKeeper 代码耦合在一起了，无法单独使用 ZAB 协议，所以一般而言，只需要理解 ZAB 协议的架构和基础原理就可以了。
TCC【最终一致性】TCC 是一个分布式事务的处理模型，将事务过程拆分为 Try、Confirm、Cancel 三个步骤，在保证强一致性的同时，最大限度提高系统的可伸缩性与可用性，又被称补偿事务。它的核心思想是针对每个操作都要注册一个与其对应的确认操作和补偿操作（也就是撤销操作）
二阶段提交协议实现的是数据层面的事务，比如 XA 规范采用的就是二阶段提交协议；TCC 实现的是业务层面的事务，TCC 可以理解为是一个业务层面的协议，可以当做为一个编程模型来看待，因此这个的应用还是非常广泛的。，TCC 的 3 个操作是需要在业务代码中编码实现的，为了实现一致性，确认操作和补偿操作必须是等幂的，因为这 2 个操作可能会失败重试。
TCC 不依赖于数据库的事务，而是在业务中实现了分布式事务，这样能减轻数据库的压力，但对业务代码的入侵性也更强，实现的复杂度也更高。所以，推荐在需要分布式事务能力时，优先考虑现成的事务型数据库（比如 MySQL XA），当现有的事务型数据库不能满足业务的需求时，再考虑基于 TCC 实现分布式事务。
Gossip【最终一致性】Gossip 协议利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。掌握这个协议不仅能很好地理解这种最常用的，实现最终一致性的算法，也能在后续工作中得心应手地实现数据的最终一致性。
Gossip 主要通过三个步骤：直接邮寄（Direct Mail）、反熵（Anti-entropy）和谣言传播（Rumor mongering）来实现最终一致性。实现数据副本的最终一致性时，一般而言，直接邮寄的方式是一定要实现的。在节点都是已知的情况下，一般采用反熵修复数据副本的一致性。当集群节点是变化的，或者集群节点数比较多时，这时要采用谣言传播的方式来实现最终一致。
Quorum NWR【最终一致性】Quorum NWR 算法非常实用，能有效弥补 AP 型系统缺乏强一致性的痛点，给业务提供了按需选择一致性级别的灵活度。实际应用中，一般的 AP 型分布式系统中（比如 Dynamo、Cassandra、InfluxDB 企业版的 DATA 节点集群）都会实现 Quorum NWR 的功能。掌握 Quorum NWR，不仅是掌握一种常用的实现一致性的方法，同时可以根据业务的特点来灵活地指定一致性级别。
N、W、R 值的不同组合，会产生不同的一致性效果：

当 W + R > N 的时候，对于客户端来讲，整个系统能保证强一致性，一定能返回更新后的那份数据。
当 W + R <= N 的时候，对于客户端来讲，整个系统只能保证最终一致性，可能会返回旧数据。

如何设置 N、W、R 值，取决于我们想优化哪方面的性能。比如，N 决定了副本的冗余备份能力；如果设置 W = N，读性能比较好；如果设置 R = N，写性能比较好；如果设置 W = (N + 1) / 2、R = (N + 1) / 2，容错能力比较好，能容忍少数节点（也就是 (N - 1) / 2）的故障。
POW【拜占庭容错】区块链中有此应用
PBFT【拜占庭容错】区块链中有此应用
本文转载自微信公众号「后端系统和架构」