专栏
天翼云开发者社区

分布式一致性协议之ZAB

2023-12-22 09:56:09 6阅读

一,前文回顾

前文《Raft协议介绍》介绍了分布式一致性协议Raft的原理和设计理念,该协议被广泛用于设计分布式架构软件系统如Nacos,etcd等,稳定可靠同时也便于理解。作为经典大数据领域早期分布式协同解决方案的代表,Zookeeper采用ZAB协议来解决分布式一致性问题。本文就来谈一谈ZAB协议;

二,认识ZAB

ZAB(ZooKeeper Atomic Broadcast)协议是用于ZooKeeper分布式协调服务的一种原子广播协议。ZooKeeper是一个分布式的开源协调服务,它提供了分布式应用程序的一致性和共享配置等功能。ZAB协议是ZooKeeper用来保持数据一致性的关键组件。

2.1 基本概念

1. 主节点(Leader)

ZAB协议中的一个节点被选为主节点,负责接收客户端的写请求并将其广播给其他节点。主节点是整个系统的决策者。

2. 从节点(Follower)

其他节点作为从节点,负责接收主节点的广播,并在本地执行相同的写操作。从节点在正常情况下不处理写请求。

3. 提议(Proposal)

提议是ZAB协议中的基本单元,代表一个写操作。每个提议都有一个唯一的编号,且包含写入的数据。

4. 事务(Transaction)

事务是一组有序的提议,代表一系列写操作。ZAB协议确保所有节点按照相同的顺序应用事务,以保持一致性。

2.2 主要特点

1. 原子广播

ZAB协议确保对ZooKeeper数据的所有更改都以原子广播的形式传播到所有的服务器节点。这意味着每个更改操作要么被所有节点接受,要么被所有节点拒绝。

2. 状态同步

ZAB协议在初始阶段通过主节点(Leader)向所有从节点(Followers)发送完整的数据快照来实现状态同步。之后,通过在快照之上应用逐个更改操作来保持状态同步。

3. 崩溃恢复

ZAB协议具有崩溃恢复的能力。当主节点崩溃或新的主节点产生时,ZAB协议确保新的主节点能够在崩溃前后的日志中进行正确的恢复。

2.3 工作原理

1. 选主阶段

在系统启动时,所有节点都是Follower。通过投票算法,节点进行选主,其中一个节点成为Leader,其他节点成为Follower。Leader负责处理客户端写请求。

2. 数据同步阶段

  • 广播提议: Leader接收到客户端的写请求后,将提议广播给所有节点。

  • 提案的投票: Follower节点接收到提议后,将投票发送给Leader。Leader只有在获得大多数节点的投票后,才会将提议标记为已提交。

  • 数据应用: 一旦提议被标记为已提交,Leader和Follower都会将提议应用到本地状态机,确保节点的数据状态一致。

3. 崩溃恢复阶段

  • 选举新的Leader: 如果Leader崩溃,剩余的节点会重新进行选主。选举出新的Leader后,数据同步阶段继续。

  • 日志恢复: 新的Leader通过保存的提议日志来恢复之前已提交的写操作,确保在崩溃前后的数据一致性。

 

三、ZAB协议与Raft协议的异同点

ZAB协议(ZooKeeper Atomic Broadcast)和Raft协议都是用于分布式系统中的一致性算法,但它们在设计和实现上有一些显著的异同点。

3.1 共同点:

1. 一致性算法

ZAB和Raft都是为了在分布式系统中保证数据一致性而设计的算法。它们都提供了选主、数据复制和一致性维护等功能。

2. 领导者选举

两者都采用了领导者选举的机制,确保系统中只有一个节点负责接收和处理客户端的写请求,从而避免了冲突和数据不一致的问题。

3. 顺序一致性

ZAB和Raft都保证了分布式系统中的顺序一致性,即所有节点在相同的时间顺序下执行相同的操作,保持相同的数据状态。

 

异同点:

1. 设计哲学

  • ZAB: ZAB协议是为了满足ZooKeeper的需求而设计的。它注重在ZooKeeper中实现原子广播,强调状态同步和一致性。

  • Raft: Raft协议则更加通用,它的设计目标是提供更易理解和更容易实现的一致性算法,可以应用于不同类型的分布式系统。

2. 日志复制

  • ZAB: ZAB协议中,主节点(Leader)负责生成并复制事务日志,确保所有节点都按照相同的顺序应用事务。

  • Raft: Raft协议中,Leader同样负责产生日志条目,但它会在大多数节点都复制了这些日志后才提交,以保证一致性。

3. 成员变更

  • ZAB: ZAB协议对成员变更(节点的动态加入或离开)的处理相对较为复杂。

  • Raft: Raft协议对成员变更的处理较为简单和直观,通过添加和删除节点实现。

4. 集群状态

  • ZAB: ZAB协议在正常工作状态下,所有节点都可以接收和处理客户端的读请求。

  • Raft: Raft协议在正常工作状态下,只有Leader节点能够处理客户端的读写请求。

5. 逻辑时钟

  • ZAB: ZAB协议使用逻辑时钟(Logical Clock)来确保事务的顺序。

  • Raft: Raft协议使用递增的索引(Log Index)来标识日志条目的顺序。

 

四,总结

ZAB和Raft都是为了解决一致性问题而设计的协议,它们在具体的实现和应用场景中有一些差异。选择使用哪种协议取决于具体的需求和系统架构。

 

 

  • 0
  • 0
  • 0
0 评论
0/1000
评论(0) 发表评论
廖****锋

廖****锋

10 篇文章 0 粉丝
关注

分布式一致性协议之ZAB

2023-12-22 09:56:09 6阅读

一,前文回顾

前文《Raft协议介绍》介绍了分布式一致性协议Raft的原理和设计理念,该协议被广泛用于设计分布式架构软件系统如Nacos,etcd等,稳定可靠同时也便于理解。作为经典大数据领域早期分布式协同解决方案的代表,Zookeeper采用ZAB协议来解决分布式一致性问题。本文就来谈一谈ZAB协议;

二,认识ZAB

ZAB(ZooKeeper Atomic Broadcast)协议是用于ZooKeeper分布式协调服务的一种原子广播协议。ZooKeeper是一个分布式的开源协调服务,它提供了分布式应用程序的一致性和共享配置等功能。ZAB协议是ZooKeeper用来保持数据一致性的关键组件。

2.1 基本概念

1. 主节点(Leader)

ZAB协议中的一个节点被选为主节点,负责接收客户端的写请求并将其广播给其他节点。主节点是整个系统的决策者。

2. 从节点(Follower)

其他节点作为从节点,负责接收主节点的广播,并在本地执行相同的写操作。从节点在正常情况下不处理写请求。

3. 提议(Proposal)

提议是ZAB协议中的基本单元,代表一个写操作。每个提议都有一个唯一的编号,且包含写入的数据。

4. 事务(Transaction)

事务是一组有序的提议,代表一系列写操作。ZAB协议确保所有节点按照相同的顺序应用事务,以保持一致性。

2.2 主要特点

1. 原子广播

ZAB协议确保对ZooKeeper数据的所有更改都以原子广播的形式传播到所有的服务器节点。这意味着每个更改操作要么被所有节点接受,要么被所有节点拒绝。

2. 状态同步

ZAB协议在初始阶段通过主节点(Leader)向所有从节点(Followers)发送完整的数据快照来实现状态同步。之后,通过在快照之上应用逐个更改操作来保持状态同步。

3. 崩溃恢复

ZAB协议具有崩溃恢复的能力。当主节点崩溃或新的主节点产生时,ZAB协议确保新的主节点能够在崩溃前后的日志中进行正确的恢复。

2.3 工作原理

1. 选主阶段

在系统启动时,所有节点都是Follower。通过投票算法,节点进行选主,其中一个节点成为Leader,其他节点成为Follower。Leader负责处理客户端写请求。

2. 数据同步阶段

  • 广播提议: Leader接收到客户端的写请求后,将提议广播给所有节点。

  • 提案的投票: Follower节点接收到提议后,将投票发送给Leader。Leader只有在获得大多数节点的投票后,才会将提议标记为已提交。

  • 数据应用: 一旦提议被标记为已提交,Leader和Follower都会将提议应用到本地状态机,确保节点的数据状态一致。

3. 崩溃恢复阶段

  • 选举新的Leader: 如果Leader崩溃,剩余的节点会重新进行选主。选举出新的Leader后,数据同步阶段继续。

  • 日志恢复: 新的Leader通过保存的提议日志来恢复之前已提交的写操作,确保在崩溃前后的数据一致性。

 

三、ZAB协议与Raft协议的异同点

ZAB协议(ZooKeeper Atomic Broadcast)和Raft协议都是用于分布式系统中的一致性算法,但它们在设计和实现上有一些显著的异同点。

3.1 共同点:

1. 一致性算法

ZAB和Raft都是为了在分布式系统中保证数据一致性而设计的算法。它们都提供了选主、数据复制和一致性维护等功能。

2. 领导者选举

两者都采用了领导者选举的机制,确保系统中只有一个节点负责接收和处理客户端的写请求,从而避免了冲突和数据不一致的问题。

3. 顺序一致性

ZAB和Raft都保证了分布式系统中的顺序一致性,即所有节点在相同的时间顺序下执行相同的操作,保持相同的数据状态。

 

异同点:

1. 设计哲学

  • ZAB: ZAB协议是为了满足ZooKeeper的需求而设计的。它注重在ZooKeeper中实现原子广播,强调状态同步和一致性。

  • Raft: Raft协议则更加通用,它的设计目标是提供更易理解和更容易实现的一致性算法,可以应用于不同类型的分布式系统。

2. 日志复制

  • ZAB: ZAB协议中,主节点(Leader)负责生成并复制事务日志,确保所有节点都按照相同的顺序应用事务。

  • Raft: Raft协议中,Leader同样负责产生日志条目,但它会在大多数节点都复制了这些日志后才提交,以保证一致性。

3. 成员变更

  • ZAB: ZAB协议对成员变更(节点的动态加入或离开)的处理相对较为复杂。

  • Raft: Raft协议对成员变更的处理较为简单和直观,通过添加和删除节点实现。

4. 集群状态

  • ZAB: ZAB协议在正常工作状态下,所有节点都可以接收和处理客户端的读请求。

  • Raft: Raft协议在正常工作状态下,只有Leader节点能够处理客户端的读写请求。

5. 逻辑时钟

  • ZAB: ZAB协议使用逻辑时钟(Logical Clock)来确保事务的顺序。

  • Raft: Raft协议使用递增的索引(Log Index)来标识日志条目的顺序。

 

四,总结

ZAB和Raft都是为了解决一致性问题而设计的协议,它们在具体的实现和应用场景中有一些差异。选择使用哪种协议取决于具体的需求和系统架构。

 

 

文章来自专栏

微服务&中间件

10 篇文章 2 订阅
0 评论
0/1000
评论(0) 发表评论
  • 0
    点赞
  • 0
    收藏
  • 0
    评论