分布式理论与分布式算法

分布式定义、主要目标、优缺点、与集中式区别；分布式 CAP 定理、PACELC 理论、BASE 理论的核心观点、应用场景等；分布式算法如 Paxos 算法、Raft 算法、Gossip 算法、两阶段提交（2PC）、三阶段提交（3PC）、一致性哈希算法、Bully 算法、Chord 算法等算法的核心思想、角色、算法过程、特性、应用场景和变种等。

—— 2025 年 2 月 3 日甲辰年正月初六立春

- - 1 分布式
  - - 1.1 分布式定义
    - 1.2 分布式优缺点
    - 1.3 分布式与集中式
  - 2 CAP 定理
  - - 2.1 CAP 三属性
    - 2.2 CAP 核心观点
    - 2.3 CAP 应用场景
    - 2.4 CAP 误区
  - 3 PACELC 理论
  - 4 BASE 理论
  - - 4.1 BASE 三属性
    - 4.2 BASE 核心观点
    - 4.3 BASE 实现机制
    - 4.4 BASE 应用场景
  - 5 分布式算法
  - - 5.1 Paxos 算法
    - 5.2 Raft 算法
    - 5.3 Gossip 算法
    - 5.4 两阶段提交（2PC）
    - 5.5 三阶段提交（3PC）
    - 5.6 一致性哈希算法（Consistent Hashing）
    - 5.7 Bully 算法
    - 5.8 Chord 算法

1 分布式

1.1 分布式定义

分布式是计算机科学中的一个研究方向，它研究如何把一个需要巨大计算能力或资源才能解决的问题分成若干个小部分，然后把这些部分分配给多个计算机进行处理，最后把这些结果综合起来得到最终结果。即分散压力。换言之，当程序和数据需要通过网络分布在多个计算机上时，我们就称它是分布式的。如分布式计算、分布式存储、分布式数据、分布式缓存、分布式文件系统等。

1.2 分布式优缺点

分布式系统的主要目标（优点）和缺点如下：

主要目标（优点）：
- 高并发：分布的目的就是为了突破单节点性能屏障。
- 高性能：分散了压力，各节点的处理速度将只受限于硬件的性能。
- 高可用：多节点避免了单节点故障导致系统不可用。
- 可扩展：可通过水平增加或删除节点的方式应对不同计算场景。
- . . .
缺点：
- 复杂度增加：由于程序和数据的分布性，设计开发时则需要考虑网络通信、数据一致性和故障处理等问题。
- 数据一致性：由于存在多节点，故需要考虑各节点间的数据一致性。
- 性能问题：由于各节点间需要通过网络通信，网络会有些许延迟，故对性能有一定影响。
- 故障排查难度增加：在分布式系统中，数据可能会流转在多个节点，当出现故障时，则需要考虑多个节点的交互。
- 部署和维护成本增加：由于多节点，则会增加部署、维护和监控的成本。
- . . . （尽管它存在这些缺点，但它带来的收益却是不可估量的！）

1.3 分布式与集中式

与分布式对应的是集中式，二者区别如下：

直观区别：集中式中程序、数据和资源等集中在中心节点上，中心节点来处理计算任务。而分布式则将这些分布在多个节点上，且每个节点都可以处理计算任务。
集中式的优点为系统复杂度低，不用考虑数据一致性，故障排查难度低，部署和维护成本低；缺点为：可靠性差、性能受限于硬件性能，扩展性低。

2 CAP 定理

CAP 定理 是分布式系统中的一个核心理论，由加州大学计算机科学家 Eric Brewer 提出。它描述了分布式系统在设计时面临的三个关键属性之间的权衡关系。CAP 定理指出，在分布式系统中，一致性（Consistency）、**可用性（Availability）**和 分区容错性（Partition Tolerance） 三种属性无法同时满足，最多只能满足其中两个。

2.1 CAP 三属性

一致性（Consistency）：
- 定义：所有节点在同一时间看到的数据是一致的。即任何读操作都能督导最新写入的数据。
- 栗子：若某个用户更新了某个数据，则其它用户在读取时应该立即看到更新后的结果。
可用性（Availability）：
- 定义：系统在任何时候都能正常使用，不会因为部分节点故障而导致整个系统不可用。
- 栗子：即使某些节点宕机，用户仍可读写数据。
分区容错性（Partition Tolerance）：
- 定义：系统在遇到网络分区（即节点间通信中断，如网络延迟、丢包、节点故障等）时，仍能够继续运行。
- 栗子：即使部分节点间出现网络故障，系统仍能够提供服务。

2.2 CAP 核心观点

如上图所示，CAP 定理指出，在分布式系统中，最多只能同时满足 CAP 中的两个属性。但是，在分布式系统中网络分区（即节点间通信中断，如网络延迟、丢包、节点故障等）时不可避免的（因为网络是不稳定的、是波动的），因此 分区容错性（P）必须选择。具体如下：

CP：即保证一致性和分区容错性，放弃可用性。在保证系统各节点间数据绝对一致时，若网络分区发生，则不能保证系统可用性。因为网络分区发生后，节点间需要同步数据，又因为要保证数据一致性，则所有节点必须停止对外提供服务，待数据同步完成后，再恢复对外服务，在此期间，系统是不可用的。
AP：即保证可用性和分区容错性，放弃一致性。在保证系统绝对可用时，若网络分区发生，则不能保证数据一致性。因为网络分区发生后，节点间需要同步数据，又因为要保证系统绝对可用，则正常节点必须保持对外提供服务，此时，需要同步数据的节点与正常节点间的数据一定是不一致的。

2.3 CAP 应用场景

CP 系统（一致性优先）：
- 特点：为了保证数据一致性，在网络分区时，系统会停止对外服务，直到数据一致。
- 栗子：分布式数据库如 zookeeper、etcd、HBase、redis、mongo db 等，配置中心 nacos 等。
- 适用场景：金融系统、交易系统等对数据极敏感的场景。
AP 系统（可用性优先）：
- 特点：为了保证系统可用性，在网络分区时，仍对外提供服务，可能会导致同一个读取操作读取到不同的结果。
- 栗子：分布式缓存 redis、分布式数据库 cassandra、消息队列 kafka、配置中心 nacos 和 eureka 等。
- 适用场景：社交网络、内容分发网络（CDN）等对可用性要求较高的场景。
CA 系统（一致性和可用性优先）：
- 特点：放弃分区容错性，则意味着常用于单机或局域网环境。在分布式系统中几乎不存在，因为一旦分布，则定然会出现网络分区。
- 栗子：传统关系型数据库如 mysql、oracle、pgsql 等。
- 适用场景：小型系统或不需要分布式架构的场景。

部分分布式系统不是绝对的 cp、ap 或 ca，其支持通过配置或其它方式在三者间进行切换，如 nacos、redis 等。

2.4 CAP 误区

CAP 不是三选二：CAP 定理不是说在任何时候都只能选择两个属性，而是在网络分区发生时，必须在 C 和 A 之间做出抉择。
CAP 不是绝对的：在实际实现中，可通过技术手段（如最终一致性、副本同步等）在 C 和 A 之间找到平衡。
CAP 不是唯一的设计原则：除了 CAP，分布式系统还需要考虑网络延迟、性能、扩展性等其它因素。

3 PACELC 理论

PACELC 理论是基于 CAP 理论扩展出来的。它考虑了这样一个问题，即：系统在大部分情况下都是稳定运行的，不会出现网络分区。所以在这种情况下，系统在设计上要均衡的其实是延迟与数据一致性的问题，要保证数据一致性，则写入和读取的延迟会增高。所以，其本质上进一步细化了分布式系统的设计选择：

若存在分区（P）：在 C（一致性）和 A（可用性）之间选择。
若不存在分区（P）：在 C（一致性）和 L（延迟）之间选择。

故，PACELC 理论不仅包含了系统出现网络分区的极端情况，又扩展出系统正常运行时的情况，是设计分布式系统的指导理论的最佳选择。

4 BASE 理论

BASE 定理由 eBay 架构师提出，是对 CAP 的一种补充和扩展，或是对 CAP 的一种具体实践或指导。其强调通过牺牲强一致性来换取系统的可用性和高性能，特别适用于需要高可用性和分区容错性的场景，即 AP 系统。

4.1 BASE 三属性

基本可用（Basically Available）：
- 定义：系统在出现故障时（如节点故障或网络分区），仍然能够提供部分功能或服务（如核心功能），而不是完全不可用。但可能会降低服务质量（如降级或增加响应时间）。
- 栗子：电商系统在大促销期间可能会关闭非核心功能（如评价系统），但核心功能（如下单、支付）仍然可用。
软状态（Soft State）：
- 定义：系统的状态可能会随着时间的推移而变化，即便没有外部输入，数据也可能不一致。换言之，系统的状态不需要时刻保持一致，允许存在中间状态，且状态的变化通常通过异步更新或后台任务完成。
- 栗子：分布式缓存中的数据可能会在一段时间后过期或更新。
最终一致性（Eventually Consistent）：
- 定义：系统在经过一段时间后，最终会达到一致状态。即不要求数据的实时一致性，运允许短时间内不一致，通过异步复制或消息传递来达到最终一致。
- 栗子：分布式数据库（Cassandra）中，数据被更新后，可能会延迟同步到所有节点，但最终所有节点的数据将会保持一致。

4.2 BASE 核心观点

BASE 的核心观点是通过牺牲强制一致性来保证系统的高可用和高性能。其优点为：

优点：
- 高可用：系统在故障时，仍可提供服务。
- 高性能：通过减少节点间同步，以提高系统的响应速度。
- 易扩展：因减少了节点间的同步，故在扩展时并不会造成系统不可用。
缺点：
- 数据不一致：在数据最终一致前，系统可能会返回旧数据或不一致的数据。
- 复杂度：实现最终一致性需要额外的机制，如冲突解决，版本控制等。

4.3 BASE 实现机制

在实际实现中，BASE 通常通过以下机制实现：

异步复制：数据通过异步更新的方式同步到其它节点。
版本控制：通过版本号或时间戳来解决数据冲突。
消息队列：通过消息队列实现数据的最终一致性。
分布式缓存：通过缓存来提高读取性能，同时允许数据延迟更新。

4.4 BASE 应用场景

BASE 适用于对可用性和性能要求高，但对一致性要求不高的场景，如：

社交网络：如用户发布的内容可在稍后同步到所有节点，不要实时一致。
电商系统：如商品库存可允许短暂不一致，但最终会保持一致。
内容分发网络（CDN）：如缓存的内容可在一段时间后更新，不需要实时同步。

5 分布式算法

分布式算法是分布式系统中的核心组成部分，用来解决数据一致性、分区容错、负载均衡、分布式寻址等问题，常用的分布式算法及其优缺点如下：

5.1 Paxos 算法

Paxos 算法是一种用于在分布式系统中达成一致性的共识算法，由 Leslie Lamport 在 1990 年提出。它能够在存在网络分区、延迟或节点故障的情况下，确保系统中多个节点就某个值达成一致。Paxos 是许多分布式系统的基础。

Paxos 的核心思想

Paxos 通过多轮投票的方式，让系统中的多个节点就某个值达成一致。其核心思想是将一致性问题分解为多个阶段，每个阶段由不同的角色参与，并通过多数派（Quorum）原则确保一致性。
Paxos 的角色

Paxos 共有三个角色，且每个节点可以同时扮演多个角色，角色如下：
- Proposer（提议者）：即提出一个值，并试图让其它节点接受该值。
- Acceptor（接受者）：即负责接受或据绝 Proposer 提出的值。
- Learner（学习者）：即学习最终被接受的值。
Paxos 的过程

Paxos 算法过程分为 Prepare 和 Accept 两个阶段：
- Prepare 阶段：
  - Proposer 选择一个全局唯一的提案编号 n，并向所有的 Acceptor 发送 Prepare 请求。
  - Acceptor 收到 Prepare 请求后，若提案编号 n 大于它之前见过的所有提案编号，则承诺不再接受编号小于 n 的提案，并返回它已经接受的最高编号的提案值（如果有）。
- Accept 阶段：
  - Proposer 在收到多数 Acceptor 的响应后，选择提案值。选择方式为在 Acceptor 返回的提案值中选择编号最大的值；若没有，则 Proposer 可以选择自己的值。
  - Proposer 向所有 Acceptor 发送 Accept 请求，请求内容包含提案编号和选择的值。
  - Acceptor 在收到 Accept 请求后，若 n 不小于它承诺的最小提案编号，则接受该提案并返回确认。
  - Proposer 在收到多数 Acceptor 的确认后，该值被选定。
Paxos 的特性
- 安全性：只有一个值会被选定，只有被提出的值才可能被选定。
- 活性：只要多数节点存活且通信正常，最终会有一个值被选定。
- 容错性：高容错性，允许少数节点故障，即在网络分区、延迟或节点故障的情况下，仍能保证一致性。
- 缺点：
  - 复杂性：理解和实现较为复杂。
  - 性能：在高并发场景下，性能可能受到影响。
Paxos 的变种

由于 Paxos 算法较为复杂，故在实践中常用其变种：
- Multi-Paxos：优化多轮提案的场景，减少 Prepare 阶段的开销。
- Raft：基于 Paxos 思想，更易理解和实现的一致性共识算法。

5.2 Raft 算法

Raft 算法是一种用于在分布式系统中达成一致性的共识算法，由 Diego Ongaro 和 John Ousterhout 在 2014 基于 Paxos 算法的思想提出。Raft 比 Paxos 更易理解和实现，同时又具有高容错性和高性能。Raft 通过将共识问题分解为更小的子问题（如领导选举、日志复制和安全性等），使得算法更加直观和易于实现。

Raft 的核心思想

Raft 的核心思想是通过在所有节点中选举一个领导者（Leader）来管理日志复制，从而简化共识过程。领导者负责接收客户端的请求，并将这些请求命令复制到其它节点（Follower），当多数节点成功复制日志后，领导者会提交日志条目，并通知其它节点。
Raft 的角色

Raft 共有三个角色，每个节点同时只能扮演一个角色，角色如下：
- Leader（领导者）：负责接收客户端请求，并将日志条目转发到其它节点；定期向其它节点发送心跳。
- Follower（跟随者）：被动接收来自 Leader 的日志条目和心跳消息；若超过一定时间未收到心跳消息，则可有机会变为 Candidate。
- Candidate（候选者）：当 Leader 失效时，Follower 可转变为 Candidate，Candidate 可发起选举尝试成为新的 Leader。
Raft 的过程

Raft 算法的过程可分为领导选举（Leader Election）和日志复制（Log Replication）两个阶段：
- 领导选举：
  - 当 Follower 超过一定时间未收到 Leader 的心跳信息时，Follower 会转变为 Candidate。
  - Candidate 向其它节点发送投票请求（RequestVote RPC）。
  - 若某个 Candidate 获得多数节点的投票，则称为新的 Leader。
  - 若多个 Candidate 同时发起选举，则可能导致选举失败，此时会重新进行选举（他们把这种现象称之为脑裂）。
- 日志复制：
  - Leader 在接收到客户端的请求后，会将该请求作为日志条目追加到自己的日志中。
  - Leader 通过 AppendEntries RPC 请求该日志条目复制到其它节点。
  - 当多数节点成功复制该日志条目后，Leader 提交该条目，并通知其它节点（Follower）提交。
  - 提交后的日志条目会被应用到状态机，执行客户端请求。
Raft 的关键机制
- Term（任期）：Raft 将时间划分为任期，每个任期从一次选举开始；每个节点维护当前任期号，并在通信时交换任期号以检测过期的 Leader 或 Candidate。
- 日志一致性：Leader 确保所有 Follower 的日志与自己的日志一致；通过强制复制不一样的日志，以确保所有节点日志的最终一致。
- 安全性检查：在选举时，Candidate 必须拥有最新的日志才能成为 Leader；确保只有包含所有已提交日志条目的节点才能成为 Leader。
Raft 的特性
- 安全性：
  - 确保只有一个 Leader。
  - 确保日志条目的最终一致性。
- 活性：只要多数节点存活且通信正常，系统就可用。
- 容错性：能够容忍少数节点的故障。
- 缺点：
  - 性能开销：在极端情况下，性能可能不如 Paxos。
  - 依赖 Leader：Leader 节点故障可能导致系统短暂不可用。
Raft 的优化
- 日志压缩：通过快照以减少日志大小，避免日志无限增长。
- 集群节点变更：支持动态增加或移除节点，通过联合共识（Joint Consensus）机制确保变更期间的安全性。

5.3 Gossip 算法

Gossip 算法或协议，也称流行病协议（Epidemic Protocol），是一种用于在分布式系统中进行信息传播和状态同步的算法。它的名称来源于单词 gossip（意为八卦或流言蜚语），它的工作方式类似于村口情报中心的八卦信息的传播：即每个节点随机选择其它节点并与之交换信息，最终所有节点都会获得相同的信息。Gossip 算法具有高度容错性、可扩展性、去中心化和易实现特性，因此被广泛应用于分布式数据库、区块链和网络协议等领域。

Gossip 的核心思想

Gossip 算法的核心思想是通过随机通信和局部信息交换，逐步将信息同步到所有节点。每个节点定期随机选择其它节点并与之交换信息，经过多次迭代后，信息会以指数级的速度传播到所有节点。由于通信时随机且局部的，所以 Gossip 算法对网络分区和节点故障具有天然的容错能力。
Gossip 的工作过程
- 信息初始化：某个节点生成一条新信息（如状态更新或事件通知）。
- 信息传播：节点定期（或触发时）随机选择其它节点（称之为 “邻居”），并将信息发送给它们。
- 信息合并：接收信息的节点将新信息与本地信息合并，并更新自己的状态。
- 迭代传播：接收信息的节点继续随机选择其它节点传播信息，直到所有节点都获得该信息。
Gossip 的信息传播模式
- 反熵模式（Anti-Entropy）：
  - 节点定期随机选择其它节点，并与之同步全部或部分状态信息。适用于确保最终一致性，如分布式数据库中的状态同步。
- 谣言传播模式（Rumor Mongering）：
  - 节点仅在接收到新信息后才会传播该信息。适用于事件通知或消息广播，如分布式系统中的故障检测。
Gossip 的特性
- 去中心化：不需要中心化的协调者，每个节点都可直接与其它节点通信。
- 容错性：即使发生网络分区或部分节点故障，信息仍能通过其它路径传播。
- 最终一致性：信息最终会传播到所有节点，但可能会存在一定延迟。
- 低负载：每个节点只需与少量节点通信，避免了广播风暴。
- 可扩展性：新增节点只需与少数节点通信即可加入系统。
- 缺点：
  - 传播延迟：信息传播到所有节点可能需要一定时间。
  - 冗余通信：节点可能多次接收到相同信息，造成一定的网络开销。
  - 最终一致性：虽然能保证最终一致性，但由于存在传播延迟，故不适用于强一致性的场景。
Gossip 的应用场景
- 分布式数据库：用于节点间的状态同步和数据一致性维护。如 Amazon Dynamo、Cassandra、redis 的 cluster 模式等。
- 故障检测：用于分布式系统中的节点健康状态检测。如 Akka 集群等。
- 内容分发网络（CDN）：用于快速传播更新或缓存失效通知。
- 物联网：用于设备间的信息共享或状态同步。
Gossip 的变种
- Push Gossip：节点主动将信息推送给其它节点。
- Pull Gossip：节点主动从其它节点拉取信息。
- Push-Pull Gossip：节点暨拉又推。

5.4 两阶段提交（2PC）

两阶段提交（Two-Phase commit，2PC）是一种经典的分布式事务协议，用于在分布式系统中确保多个节点上的操作具有原子性。2PC 是分布式事务的基础协议之一，广泛应用于分布式数据库、分布式存储等领域。

2PC 的核心思想

2PC 的核心思想时通过一个协调者（Coordinator）来管理多个参与者（Participants），将事务的提交过程分为准备和提交两个阶段。
2PC 的角色
- 协调者（Coordinator）：负责管理事务的提交过程，向参与者发送准备和提交请求。
- 参与者（Participant）：执行本地事务，并根据协调者的指令提交或回滚事务。
2PC 的工作过程
- 准备阶段（Prepare Phase）：
  - 协调者向所有参与者发送 Prepare 请求，询问它们是否准备好提交事务。
  - 参与者收到 Prepare 请求后：
    - 若参与者可以提交事务，则执行本地事务但不提交，记录日志（Undo 和 Redo 日志），并向协调者发送 Yes 响应。
    - 若参与者不能提交事务（如由于本地故障或约束冲突），则向协调者发送 No 响应。
- 提交阶段（Commit Phase）：
  - 协调者根据参与者的响应决定事务的最终结果：
    - 若所有参与者都返回 Yes，则协调者向所有参与者发送 Commit 请求。
    - 若任意一个或多个参与者返回 No，则协调者向所有参与者发送 Abort 请求。
  - 参与者收到 Commit 或 Abort 请求后：
    - 若收到 Commit 请求，则提交本地事务并释放资源。
    - 若收到 Abort 请求，则回滚本地事务并释放资源。
  - 参与者完成提交或回滚后，向协调者发送 Ack 响应。
  - 协调者收到所有参与者的 Ack 后，事务结束。
2PC 的特性
- 原子性：废话，都说了人是分布式事务协议，当然具有原子性咯。
- 一致性：事务完成后，系统状态保持一致。
- 阻塞性：若协调者或参与者在某些阶段发生故障，则可能导致系统阻塞。
- 单点故障：协调者若是单点，在发生协调者故障时，事务可能无法完成。
- 缺点：
  - 单点故障：协调者若是单点，在发生协调者故障时，事务可能无法完成。
  - 阻塞问题：若协调者或参与者在某些阶段发生故障，则可能导致系统阻塞。
  - 性能开销：事务过程需要多次网络通信和日志记录，性能开销较大。
  - 不适合大规模分布式系统：由于存在单点问题和性能开销，故 2PC 不适合大规模分布式系统。
2PC 的应用场景
- 分布式数据库：如 mysql 的 XA 事务、oracle 的分布式事务。
- 消息队列：如 RocketMQ 的事务消息。
- 微服务事务架构：用于跨服务的分布式事务管理。
2PC 的变种
- 三阶段提交（3PC）：在 2PC 的基础上增加一个预提交阶段，减少阻塞问题。
- Paxos Commit：基于 Paxos 算法实现分布式提交，以避免单点故障。
- 分布式事务框架：如 Google 的 Spanner 和阿里巴巴的 Seata，通过优化协调者和参与者的交互方式，提高性能和容错性。

5.5 三阶段提交（3PC）

三阶段提交（Three-Phase Commit，3PC）是基于两阶段提交（2PC）的改进版本，旨在解决 2PC 的单点故障和阻塞问题。3PC 通过引入第三个阶段预提交阶段来减少事务阻塞的可能性，并提高系统的容错性。尽管 3PC 在理论上比 2PC 更健壮，但由于其复杂性和额外的网络通信开销，故其实际应用相对较少。

3PC 的核心思想

3PC 的核心思想是通过引入第三个阶段：预提交阶段来减少事务阻塞的可能性。
3PC 的角色
- 协调者（Coordinator）：负责管理事务的提交过程，向参与者发送 CanCommit、PreCommit 和 DoCommit 请求。
- 参与者（Participant）：执行本地事务，并根据协调者的指令进入与提交状态、提交或回滚事务。
3PC 的工作过程
- 准备阶段（CanCommit Phase）：
  - 协调者向所有参与者发送 CanCommit 请求，询问它们是否准备好提交事务。
  - 参与者收到 CanCommit 请求后：
    - 若参与者可以提交事务，则向协调者发送 Yes 响应。
    - 若参与者不能提交事务（如由于本地故障或约束冲突），则向协调者发送 No 响应。
- 预提交阶段（PreCommit Phase）：
  - 协调者根据参与者的响应决定是否进入预提交阶段：
    - 若所有参与者都返回 Yes，则协调者向所有参与者发送 PreCommit 请求。
    - 若任意一个或多个参与者返回 No，则协调者向所有参与者发送 Abort 请求。
  - 参与者收到 PreCommit 请求后：进入预提交状态，记录日志，并向协调者发送 Ack 响应。
  - 参与者收到 Abort 请求后：直接回滚事务并释放资源。
- 提交阶段（DoCommit Phase）：
  - 协调者在收到所有参与者的 Ack 响应后，向所有参与者发送 DoCommit 请求。
  - 参与者收到 DoCommit 请求后：提交本地事务并释放资源。
  - 若参与者收到 Abort 请求，则直接回滚事务。
3PC 的特性
- 容错性：在协调者单点故障时，参与者可以根据超时机制自动决定提交或回滚事务。
- 减少阻塞：通过引入预提交阶段，减少了事务阻塞的可能性。
- 缺点：
  - 网络通信开销大：由于增加了一个阶段，故需要更多的网络开销。
  - 复杂度高：较 2PC 而言复杂度高。
  - 实际使用较少：由于复杂度和网络开销，实际使用较少。
3PC 应用场景
- 3PC 适用于对一致性和容错性要求较高的分布式系统，但由于其复杂度和网络开销，实际使用较少。通常会使用其它协议（如 Paxos 或 Raft 等）或优化后的 2PC 变种来实现分布式事务。

5.6 一致性哈希算法（Consistent Hashing）

一致性哈希（Consistent Hashing）算法是一种特殊的哈希技术，广泛用于分布式系统中数据分布和负载均衡的场景。其核心目标是解决传统哈希方法在节点增减时导致的全局数据重新映射问题，从而减少数据迁移的开销，以提高系统的可扩展性和稳定性。一致性哈希由 David Karger 等人于 1997 年提出，主要用于分布式缓存系统（如 Memcached、redis 等）和分布式存储系统（如 Amazon Dynamo、Cassandra 等）。

一致性哈希的核心思想

一致性哈希的核心思想是将数据和节点映射到一个固定的哈希环上，通过环上的位置关系确定数据的归属节点。当节点增减时，只会影响环上相邻节点的数据，而不会导致全局数据的重新映射。
一致性哈希的工作原理
- 哈希环构建：
  - 将哈希值空间组织成一个虚拟的圆环（通常 2^32 或 2^64 个虚拟槽位，成顺时针方向）。
  - 对每个节点计算哈希值，并将其映射到环上的某个位置。
- 数据映射：
  - 对每个数据项计算哈希值（如 hash(key) % n，n 取 2^32 或 2^64），并将其映射到环上的某个位置。
  - 数据项归属于环上顺时针方向最近的节点。
- 节点增减：
  - 当增加节点时，只需将新节点插入环中，并将相邻节点上的部分数据迁移到新节点。
  - 当减少节点时，只需将失效节点的数据迁移到顺时针方向上的下一个节点上。
- 虚拟节点：
  - 一致性 hash 算法因为节点分布不均匀或在节点太少的情况下，会造成缓存热点的问题。为了解决这种热点问题，一致性 hash 算法引入了虚拟节点机制，即对每一个节点计算多个 hash，每个计算结果位置都作为一个虚拟节点。这样就实现了数据的均匀分布，负载均衡。
一致性哈希的示例

如图所示，将 4 个节点按照 “ip + 名称” 哈希取模，即 location = hash(ip + 名称) % n，然后，4 个节点落在了 hash 环上如图所示的四个位置。当一个请求到达时，对 key 也进行哈希取模，假设其落在了如图所示的位置，然后顺时针进行查找，找到节点 2，即请求 key 命中了节点 2。这便是一个简单的寻址过程。

虚拟节点如物理节点 A 对应虚拟节点 A1、A2、A3，物理节点 B 对应虚拟节点 B1、B2、B3 等。
一致性哈希的特性
- 数据分布均匀：通过哈希函数将数据和节点均匀分布到哈希环上（实际上它是通过虚拟节点提高均匀性的）。
- 可扩展性：节点增减时，只需迁移少量数据。
- 负载均衡：数据均匀分布在节点上，避免热点问题。
- 容错性：节点故障时，数据会自动迁移到顺时针方向上的下个节点。
- 缺点：
  - 复杂度高：需要维护哈希环和虚拟节点。
  - 数据倾斜：若节点数量较少，则可能导致数据分布不均匀（可通过虚拟节点缓解）。
一致性哈希的应用场景
- 分布式缓存系统：用于缓存数据的分布和负载均衡。如 Memcached、Redis Cluster（以前是一致性哈希，现在是哈希槽？）。
- 分布式存储系统：用于数据分片和副本管理。如 Amazon Dynamon、Cassandra 等。
- 分布式数据库：用于数据分片和集群管理。如 MongoDB、Couchbase 等。
- 负载均衡器：用于请求的路由和转发。如 nginx、HAProxy 等。

5.7 Bully 算法

Bully 算法是一种用于分布式系统中选举领导者的算法，由 Garcia-Molina 在 1982 年提出。其核心思想是通过节点之间的比较（通常比较节点 ID 的大小）来确定领导者，适用于节点故障后需要重新选举领导者的场景。bully 意为 ”霸凌“，ID 大的节点通过霸凌 ID 小的节点胜出而成为领导者。

Bully 的核心思想

Bully 的核心思想是每个节点都有一个唯一的 ID，ID 越大的优先级越高；当节点检测到领导者故障时，会发起选举过程；选举过程中，ID 较大的节点会霸凌 ID 较小的节点，成为领导者。
Bully 的角色
- 领导者（Leader）：负责协调系统的工作，定期向普通节点发送心跳消息以表明其存活。
- 普通节点（Node）：参与选举的过程，可能成为领导者。
Bully 的工作过程
- 检测领导者失效：当某个普通节点检测到领导者失效时（如超时未收到心跳消息），会发起选举。
- 发起选举：
  - 节点向所有 ID 比自己大的节点发送 Election 消息。
  - 若未收到其它节点的响应，则该节点认为自己是最优候选者，宣布自己是领导者。
  - 若收到响应，则等待其它节点宣布选举结果。
- 响应选举：
  - 当节点收到 Election 消息时，若自己的 ID 比发送者大，则恢复 Alive 消息，并开始自己的选举过程。
  - 若自己小，则不回复。
- 宣布领导者：
  - 若某个节点在发起选举后未收到任何 Alive 消息，则宣布自己是领导者，并向所有节点发送 Coordinator 消息。
  - 其它节点收到 Coordinator 消息后，确认新的领导者。
Bully 的特性
- 复杂度：简单直观，易理解，易实现。
- 容错性：能够处理网络分区和节点故障。
- 缺点：
  - 依赖节点 ID：选举结果由 ID 决定，ID 最大的胜出。
  - 消息复杂度：在最坏情况下，消息复杂度为 O(n^2)，其中 n 是节点数量。
  - 不适合大规模系统：由于消息开销大，故不适合大规模或多节点系统。
Bully 的应用场景
- 小规模分布式系统：如局域网内的分布式应用。
- 实时系统：需要快速选举领导者的场景。
- 嵌入式系统：资源受限但需要容错能力的系统。

5.8 Chord 算法

Chord 算法是一种用于分布式哈希表（Distributed Hash Table，DHT）的协议，由 Ion Stoica 等人于 2001 年提出。其核心目标是在大型分布式系统中高效地定位数据或节点。

Chord 的核心思想

Chord 的核心思想是将节点和数据映射到一个逻辑环（通常是一个 2^m 大小的哈希空间，m 是哈希值的位数）上，并通过指针表（Finger Table）来加速查找过程，从而实现高效的节点发现和数据路由。
Chord 的角色
- 哈希环：通常使用 2^m 大小的哈希空间，m 为哈希值的位数。
- 节点 ID：每个节点通过哈希函数生成一个唯一 ID，映射到哈希环上。
- 后继节点：每个节点负责环上从自己到下一个节点之间的数据。
- 指针表（Finger Table）：每个节点维护一个指针表，包含 m 各条目，指向环上特定位置的节点，用于加速查找过程。
- 数据键：数据项通过哈希函数生成键，映射到哈希环上。
Chord 的工作机制
- 增加节点：
  - 新节点通过哈希函数生成 ID，加入到哈希环。
  - 新节点查找自己的后继节点，并通知相关节点更新其后继节点。
  - 新节点初始化自己的 Finger Table，并通知其它节点更新 Finger Table。
- 删除节点：
  - 节点删除时，通知其后继节点更新其后继关系。
  - 将离开节点负责的数据迁移到其后继节点。
  - 更新其它节点的 Finger Table。
- 查找数据：
  - 当某个节点需要查找某个键时，先检查其是否在自己负责的范围内。
  - 若不在，则通过 Finger Table 找到离目标键最近的节点，并转发查找请求。
  - 重复上述过程，直到找到负责该键的节点。
Chord 的特性
- 高性能：查找效率高，查找时间复杂度为 O(log n)，n 表示节点数量。
- 扩展性：支持节点动态增减且影响范围小。
- 负载均衡：数据和节点均匀分布在哈希环上。
- 容错性：可处理节点故障和数据迁移。
- 缺点：
  - 复杂度高：需要维护节点后继关系和 Finger Table。
  - 维护开销：节点增减时需要更新多个节点的 Finger Table。
  - 不适合小规模分布式系统：杀鸡焉用宰牛刀。
Chord 的应用场景
- 分布式文件系统：用用于快速定位和管理文件块，如 CFS、lvy 等。
- 分布式存储系统：用于数据分片和副本管理，如 Amazon Dynamo、Cassandra 等。
- P2P 网络：用于资源定位和节点发现，如 BitTorrent 等。