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的事件是包含数据的,并且通常情况下连续的更新不会被合并通知,而是逐条通知到客户端。
相关推荐
橘猫云计算机设计2 分钟前
net+MySQL中小民营企业安全生产管理系统(源码+lw+部署文档+讲解),源码可白嫖!
数据库·后端·爬虫·python·mysql·django·毕业设计
黄嚯嚯8 分钟前
Mysql8.0 推出的强大功能 窗口函数(Window Functions)
数据库·mysql
特立独行的猫a14 分钟前
redis客户端库redis++在嵌入式Linux下的交叉编译及使用
linux·数据库·c++·redis·redis客户端库
程序猿零零漆35 分钟前
【金仓数据库征文】金仓数据库:国产化浪潮下的技术突破与行业实践
数据库·金仓数据库 2025 征文·数据库平替用金仓
浩浩测试一下1 小时前
SQL注入高级绕过手法汇总 重点
数据库·sql·安全·web安全·网络安全·oracle·安全架构
Pasregret1 小时前
缓存与数据库一致性深度解析与解决方案
数据库·缓存·wpf
skywalk81631 小时前
Graph Database Self-Managed Neo4j 知识图谱存储实践2:通过官方新手例子入门(未完成)
数据库·知识图谱·neo4j
Lucky GGBond1 小时前
MySQL 报错解析:SQLSyntaxErrorException caused by extra comma before FROM
数据库·mysql
Claudio2 小时前
【MySQL】联合索引和覆盖索引(索引失效的误区讲解+案例分析)
数据库
纪元A梦2 小时前
Redis最佳实践——性能优化技巧之监控与告警详解
数据库·redis·性能优化