ZK和ETCD的产品对比和差异

ZK和ETCD的产品对比和差异

  • [1. 底层实现](#1. 底层实现)
    • [1.1 高可用机制](#1.1 高可用机制)
    • [1.2 数据结构](#1.2 数据结构)
  • [2. 客户端视角](#2. 客户端视角)
    • [2.1 临时数据](#2.1 临时数据)
    • [2.2 监听机制](#2.2 监听机制)

探讨zk和etcd的底层实现以及客户端使用上的差异。

更多关于分布式系统的架构思考请参考文档关于常见分布式组件高可用设计原理的理解和思考


1. 底层实现

1.1 高可用机制

  • 相同点:满足quorum机制(大多数同意原则),数据高度可靠,数据最终一致。
  • 不同点:zk基于ZAB协议(基于paxos协议),etcd基于raft协议

1.2 数据结构

  • zookeeper: 目录结构
  • etcd: k-v结构
    但etcd的key可以是任意字符串同时在存储上实现了key有序排列,所以仍旧可以模拟出父子目录关系,例如:key=/a/b/c、/a/b、/a

2. 客户端视角

2.1 临时数据

  • 相同点:zk、etcd都支持临时数据过期删除机制
  • 不同点:
    zookeeper通过session机制实现,当客户端掉线一段时间,对应的zookeeper session会过期,那么对应的临时节点就会被自动删除。
    etcd中对应的是lease租约机制,通过该机制实现了key的自动删除,可以在set key的同时携带lease ID,当lease过期后所有关联的key都将被自动删除。

2.2 监听机制

  • 相同点:zk、etcd都支持数据变动时,通知客户端
  • 不同点:
    zookeeper的事件模型非常可靠,不会出现发生了更新而客户端不知道的情况,但是特点也很明显:事件不包含数据,仅仅是通知变化。 多次连续的更新,通知会合并成一个;即,客户端收到通知再次拉取数据,会跳过中间的多个版本,只拿到最新数据。 这些特点并不是缺点,因为一般应用只关注最新状态,并不关注中间的连续变化。
    etcd的事件是包含数据的,并且通常情况下连续的更新不会被合并通知,而是逐条通知到客户端。
相关推荐
·薯条大王3 小时前
MySQL联合查询
数据库·mysql
morris1315 小时前
【redis】redis实现分布式锁
数据库·redis·缓存·分布式锁
hycccccch6 小时前
Canal+RabbitMQ实现MySQL数据增量同步
java·数据库·后端·rabbitmq
这个懒人6 小时前
深入解析Translog机制:Elasticsearch的数据守护者
数据库·elasticsearch·nosql·translog
Yan-英杰7 小时前
【百日精通JAVA | SQL篇 | 第二篇】数据库操作
服务器·数据库·sql
NineData7 小时前
NineData云原生智能数据管理平台新功能发布|2025年3月版
数据库
百代繁华一朝都-绮罗生8 小时前
检查是否存在占用内存过大的SQL
数据库·sql
吾日三省吾码8 小时前
Python 脚本:自动化你的日常任务
数据库·python·自动化
CZIDC9 小时前
win11 系统环境下 新安装 WSL ubuntu + ssh + gnome 桌面环境
数据库·ubuntu·ssh
直裾9 小时前
Mapreduce的使用
大数据·数据库·mapreduce