etcd / ZooKeeper / Consul 对比

CH-23-01-019·约 18 分钟·分布式系统与高并发设计·更新 2026-08-12

想象你是一个大型科技园区的物业总监：园区里有几十栋楼、几百个商家、上千名住户，大家需要互相对齐“支付服务部署在哪台机器”“今天的配置参数是什么”“谁在用那把会议室钥匙”。你不可能挨家挨户敲门问，于是你请来了三套“物业协调系统”，它们都叫分布式协调服务。第一套是 etcd，它像一个现代智能社区：所有信息以“房号-内容”的形式存在一块电子大屏上，住户通过手机群随时收到变更推送；遇到重要决策，全体业主电子投票选出一位“楼长”，由楼长统一记录工作日志。第二套是 ZooKeeper，它像一个老派单位大院：信息按“院-楼-栋-室”的树形档案柜层层摆放，住户凭临时门卡进出，变更通过贴公告单次告知。第三套是 Consul，它像一个商业综合体：除了电子白板，还有一份“商户名录”和“健康巡查表”，任何新商家都要先在前台登记，访客通过标准窗口（REST API）办事。三套系统都能解决“服务发现、配置管理、分布式锁”这类协调问题，但思路完全不同。本文从共识算法、数据模型、API 风格、Watch 机制四个维度拆解差异，并给出生产环境的选型建议。

岗位关联

掌握这套对比，你就能在架构设计中快速做取舍：Kubernetes 的配置该交给 etcd，Kafka 的协调该依赖 ZooKeeper，还是让 Consul 接管整个服务网格？这是每个分布式后端工程师的必修课。

可视化演示
协调服务总览
共识算法对比
数据模型差异
API 风格对比
Watch 机制对比
选型与运维实践
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

对比etcd、ZooKeeper与Consul在共识算法、数据模型与watch机制上的差异，展示Raft/ZAB仲裁写入、MVCC修订与ZNode树、以及流式监听通知。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Raft仲裁写入 Leader广播日志至多数节点即提交 ZooKeeper用ZAB原子广播 quorum = N/2+1 etcd与Consul采用Raft，ZK采用ZAB

协调服务总览

想象你是一个大型科技园区的物业总监。园区里的服务程序就像一群住户：有的需要查“支付服务现在部署在哪台机器”（服务发现），有的需要领取同一份配置文件（配置管理），有的要抢同一把会议室钥匙（分布式锁）。没有一套协调系统，程序之间就像住户摸黑找邻居，乱成一团。

etcd、ZooKeeper 和 Consul 正是为解决这些问题而生的“协调服务”。它们都是 CP 型系统（优先保证强一致），都提供“写入数据 + 监听变化”两大核心能力，但各自对信息的组织方式完全不同：etcd 像一张巨大的键值表，ZooKeeper 像一棵层级分明的树，Consul 则像商业综合体的管理前台，除了键值表，还多了一份“商户名录”和“健康巡查记录”。

技术上，三者都建立在“多数派共识”之上：无论哪个节点收到写请求，都要让集群中超过一半的节点确认，才能视为提交成功。这决定了它们的可用性边界——任何需要 CAP 权衡的架构决策，本质上都在回答一个问题：你的系统能容忍几个节点同时宕机？

三个物业虽风格不同，但都必须遵守“过半同意”的底层规矩：就像业委会做重大决定要获得超过一半业主的支持。这正是它们能保证数据一致性的根基，也是后续一切对比的出发点。

N \ge 2F + 1

公式说的是：如果你希望系统能容忍 F 台节点同时宕机，那么集群至少要有 2F+1 台节点。例如想容忍 2 台宕机，至少需要 5 台。etcd、ZooKeeper、Consul 生产部署都遵循这个规律。

N集群总节点数量：N 代表整个集群中运行的服务器总数，常见部署规模是 3、5、7 节点。
$N$
F可容忍故障数：F 代表你希望系统在同时宕机的机器数量内仍能正常对外服务。
$F$
多数派约束要让系统能承受 F 台故障，节点总数 N 至少是 F 的两倍再加一，这就是多数派容错模型。
$N \ge 2F + 1$

共识算法对比

业委会的决策机制，决定了整个小区的行动效率。etcd 采用的 Raft，像一场“电子投票”：每个任期（term）全体节点投票选出一位“楼长”，所有写请求都必须经过楼长，楼长把决定记录在工作日志里，发给每一户，收到超过一半住户的确认回执才算生效。如果楼长失联，大家会开启新一轮投票。

ZooKeeper 采用的 ZAB 协议则更像“两会议程”：提案先进入发现阶段，选出临时议长；同步阶段，新议长把提案编号（zxid）广播给所有节点补日志；最后才进入广播阶段，正式提交决议。ZAB 的优势是严格按 zxid 顺序执行，谁先到谁先处理，但选主期间会短暂暂停读写，对延迟更敏感。

Consul 底层同样用 Raft，因此“电子投票”逻辑与 etcd 相似，但其 HTTP 读取支持 stale 模式，允许 Follower 返回略旧的目录数据，在一致性上做了一点让步。Raft 与 ZAB 有各自的目标：Raft 追求可理解性和工程可实现性，ZAB 追求严格的全局事务顺序。无论哪种方案，最终都要凑够多数派：

无论楼长还是议长，都要拿到“过半选票”才名正言顺；这正是共识算法的核心——多数派裁定，避免脑裂。理解了这一点，就理解了三个系统为什么在故障容错上如此相似、又在协议细节上如此不同。

quorum = \left\lfloor \frac{N}{2} \right\rfloor + 1

以 N=5 为例：quorum = 2 + 1 = 3，即 3 台节点确认才能提交。提交需要的节点数总是“过半”，因为这样就永远不可能出现两个同时获胜的提交。

总节点数 N设集群一共 5 台节点，N=5。
$N = 5$
取半下取整N 除以 2 并向下取整，得到 2。
$\left\lfloor \frac{5}{2} \right\rfloor = 2$
加 1 得多数最少需要 3 台节点达成一致，这一数量就是法定多数。
$\left\lfloor \frac{N}{2} \right\rfloor + 1 = 3$

数据模型差异

同一个小区里，物业的档案格式决定了查询效率。etcd 像一面巨大的“电子储物柜”，每个柜子贴一个标签（key），比如 services/payment/addr，你要哪个直接报标签，底层引擎能以接近常数的代价取到。ZooKeeper 则像一栋档案楼，必须走“院-楼-栋-室”的路径逐级进入（znode 树），寻址耗时与树的深度成正比。Consul 更像“商业综合体前台+商户名录”，除了储物柜，还有一份随时更新的商户登记表（service catalog）和体检报告（health check）。

在 etcd 中，每个键都带版本号 mod_revision，配合租约（lease）可以自动过期，非常适合存放“节点心跳”“临时配置”这类有时效的数据。ZooKeeper 的 znode 分为持久节点、临时节点和顺序节点：临时节点与会话绑定，会话结束自动删除；顺序节点自带递增编号，这是分布式锁的最经典构件。Consul 的 KV 存储支持前缀遍历，同时其服务目录把“节点-服务-健康状态”保存在一起，天然适合服务发现。

两套模型没有绝对优劣：KV 牺牲了层级表达，换取了 API 的简洁和批量操作的高效；树形结构提供了路径权限和层次语义，但每个 znode 的数据量通常建议控制在 1MB 以下。从计算机视角看：

三种物业各有各的“档案柜”：储物柜、档案楼、前台目录。选择存储模型，本质上是选择你希望如何组织业务信息、如何做权限控制，以及你能接受多大的操作延迟。

T_{\text{KV}} = O(1), \qquad T_{\text{path}} = O(d)

这里 T_KV 是 etcd 键值查询的理论耗时，T_path 是 ZooKeeper 沿路径逐级寻址的耗时，d 为路径深度。KV 模型在单次读写上更直接，树形模型在分层权限管理上更有优势。

KV 查询成本在 etcd 的扁平键值表中，通过索引可以直接定位目标键，不受数据总量影响。
$T_{\text{KV}} = O(1)$
树形查询成本ZooKeeper 必须沿路径逐级进入子节点，每层一次查找，总时间和深度 d 成正比。
$T_{\text{path}} = O(d)$
对比结论当层级很深时，树形模型的定位开销会明显上升；这也是 etcd 在大规模配置场景中更轻量的原因之一。
$O(1) < O(d)$

API 风格对比

住户到物业中心办事时，面对的是不同风格的窗口。etcd 提供的是“自助一体机”——gRPC 高效接口，数据用二进制 Protobuf 表示，同时支持流式传输和批量操作；ZooKeeper 更像“排队填表”——它采用会话式编程模型，客户端先建立会话，再像操作文件系统一样调用 create、delete、getData；Consul 则是“标准化服务台”——所有能力都暴露为 HTTP REST 接口，用 curl 就能调用，还附带 DNS 接口，运维人员上手成本最低。

从工程角度看，etcd v3 的 gRPC 接口支持多路复用，一个连接上可以并发处理大量请求，并且内置事务 API：compare-and-swap（比较再交换），让“锁”和“选主”等操作可以原子完成。ZooKeeper 的 API 语义更底层，客户端需要手动管理 session 状态、重连与回调，对开发者的协议理解要求更高。Consul 的 REST API 和 JSON 输出为可读性而生，但高频写场景下，JSON 序列化和 HTTP 开销会比 etcd 更高。

这三类 API 风格的差异，可以简单用序列化体积来感受：

如果你喜欢用 curl 快速调试，Consul 最亲切；如果追求极致的写性能和流式能力，etcd 更合适；如果你的团队已经深度使用 ZooKeeper 客户端生态，那么会话式接口虽然繁琐，但足够成熟可靠。

S_{\text{protobuf}} \approx S_{\text{json}} \times 0.25

同一个数据对象，Protobuf 编码后的大小大约是 JSON 的四分之一。gRPC 因此适合高吞吐、长连接场景；REST 则因为人类可读、生态通用而适合运维与跨语言集成。

原始 JSON 体积JSON 携带大量花括号、冒号和字段名，可读性好但冗余度高。
$S_{\text{json}}$
压缩比例Protobuf 使用字段编号和紧凑二进制编码，典型压缩率约为 0.25。
$\times 0.25$
结果含义序列化体积变小后，网络传输和解析 CPU 消耗都随之下降，这是 etcd 高吞吐的重要来源。
$S_{\text{protobuf}} \approx S_{\text{json}} \times 0.25$

Watch 机制对比

物业通知住户的方式，决定了信息的实时性。etcd 的广播是“微信群实时推送”——客户端建立一条 gRPC 长连接，之后键的任何变化都会在流上持续推送，还可以按前缀订阅一批键；ZooKeeper 的经典广播是“墙上贴告示”——你注册一次 watch，被触发一次后这张告示就撕掉了，想继续听，必须再贴一次；Consul 的通知则像“打电话查询”——客户端每隔一段时间带着索引号打电话问“有没有新消息”，没有就挂断后过会儿再打，这叫阻塞查询。

etcd v3 的流式 watch 不仅支持前缀范围，还支持从指定版本号（revision）回放历史事件，这让客户端崩溃恢复后能补拉错过的变更。ZooKeeper 经典 watch 是一次性触发，getData 或 exists 注册的监听器只能收到一次通知，之后必须重新注册；ZooKeeper 3.6+ 虽然引入了持久监听器，但传统语义在存量系统中仍占主流。Consul 的阻塞查询通过 index 参数实现：服务器只在数据版本变化时才返回，其余时间挂起请求，既减少了空轮询，又保持了 HTTP 的简单性。

若只看某个客户端在一段时间内经历 n 次变更，三种机制的开销可以粗略比较：

推送最优、轮询次之、一次性通知最繁琐——这是选择协调服务时一个容易被忽略、却在高并发场景下影响巨大的细节。

C_{\text{etcd}} = 1, \qquad C_{\text{ZK}} = n, \qquad C_{\text{consul}} = \lceil n/T \rceil

假设一个客户端持续监听 n 次变化：etcd 只需建立 1 条长连接；ZooKeeper 需要反复重新注册 n 次；Consul 以固定间隔 T 轮询，请求次数约为 n/T。流式推送在事件密集场景下的优势一目了然。

etcd 的流式代价一条 gRPC 长连接全程复用，事件到来直接推送给客户端。
$C_{\text{etcd}} = 1$
ZooKeeper 的重注册代价每次 watch 触发后失效，n 次变更带来 n 次重新注册。
$C_{\text{ZK}} = n$
Consul 的轮询代价每 T 次变更才轮询一次，请求次数近似为向上取整的 n/T。
$C_{\text{consul}} = \lceil n/T \rceil$

选型与运维实践

到了收尾阶段，你必须为不同的小区挑选合适的物业公司。选型没有绝对王者，只有最匹配：如果你的生态是 Kubernetes 和云原生，etcd 是毫无疑问的主角，它承担着存储集群全部状态的重任；如果你的生态是 Kafka、HBase、Hadoop 这类大数据组件，ZooKeeper 是它们的默认协调底座；如果你的核心诉求是服务发现、健康检查、多数据中心和 API 网关集成，Consul 的一站式能力会让你事半功倍。

在实际选型中，需要把需求量化成指标。比如：是否需要强一致配置存储？是否需要健康检查？是否需要跨机房同步？团队熟悉哪种协议？把这些需求向量化为评分公式，可以写成一个简单的加权决策模型：

选型之后，运维同样关键：etcd 要注意磁盘碎片化需要定期 defrag，ZooKeeper 要关注 JVM 堆内存与连接数上限，Consul 的 agent 常驻内存占用不可忽视。没有完美的物业，只有愿意持续维护的团队。

\text{Best} = \operatorname*{arg\,max}_{S \in \{etcd, ZK, Consul\}} \sum_{i} w_i \cdot q_i(S)

公式的业务含义是：为每个候选系统，在多个维度（一致性、性能、生态、运维成本等）上打分，乘以权重后求和，得分最高的系统就是当前业务的最佳选择。

候选集合 S我们只在 etcd、ZooKeeper、Consul 三个系统中选择。
$S \in \{etcd, ZK, Consul\}$
权重 w_i每个维度的重要程度不同，例如“生态兼容”权重高，则 Kafka 场景会偏向 ZK。
$w_i$
得分最大化把各维度得分加权求和，取 argmax 得到总分最高的系统。
$\operatorname*{arg\,max}_{S} \sum_{i} w_i \cdot q_i(S)$

AI 应用场景

AI训练集群的配置下发中心

阶段：分布式训练协调

解决的问题：在 PyTorch/DeepSpeed 多机训练中，所有 Worker 需要同步读取超参数、模型路径、学习率等配置。传统方式把配置写在每个节点的环境变量里，改一次配置要重启所有节点，效率低且易出错。用 etcd 的租约 + watch，可以做到配置秒级下发。

具体案例：某团队训练千亿参数大模型时，把 global step 与 checkpoint 路径写入 etcd，各 Worker watch 对应前缀；主进程更新 step 后，所有 Worker 自动感知并触发断点保存。故障恢复时新 Worker 也能从指定 revision 回放事件。

推理服务注册与动态发现

阶段：推理服务部署与弹性伸缩

解决的问题：多个模型推理实例（如 vLLM、TGI）在 Kubernetes 中动态扩缩容，API Gateway 必须实时知道“哪个 Pod 在哪个端口提供服务”。用 Consul 的服务注册 + 健康检查，实例上线自动登记、异常自动摘除，比手工维护 Nginx 上游列表可靠得多。

具体案例：某 AI 应用将不同版本的翻译模型注册成 Consul 服务，网关通过 DNS 接口解析到可用实例；灰度发布时新版本实例注册后先不接流量，等待健康检查通过再切换，实现平滑升级。

数据管道分布式锁

阶段：数据准备与调度

解决的问题：多个 Spark/Flink 任务可能同时触发同一份数据清洗，必须保证只有一个任务在跑。ZooKeeper 的临时顺序节点是实现分布式锁的经典方案：创建带序号的临时节点，编号最小者获得锁，任务结束或崩溃时临时节点自动消失，后续任务自动接管。

具体案例：某数据平台用 ZooKeeper 协调 ETL 任务，多个 JobManager 竞争同一把锁，避免重复写入训练样本。锁的持有时间与会话绑定，网络分区时不会留下死锁。

Python 演示

python42 行

def simulate_etcd(updates, clients=3):    """流式 watch：每个客户端一条长连接，事件不断在连接上流动"""    connections = clients    messages = updates * clients    reconnects = 0    return connections, messages, reconnects  def simulate_zookeeper(updates, clients=3):    """一次性 watch：每次事件触发后，客户端都要重新注册监听"""    connections = 0    messages = 0    reconnects = 0    for _ in range(updates):        for _ in range(clients):            connections += 1            reconnects += 1            messages += 1    return connections, messages, reconnects  def simulate_consul(updates, clients=3, poll_interval=3):    """阻塞查询：每隔 poll_interval 次更新发起一次长轮询请求"""    polls = updates // poll_interval + 1    connections = polls * clients    messages = polls * clients    return connections, messages, 0  def main():    updates = 30    etcd = simulate_etcd(updates)    zk = simulate_zookeeper(updates)    consul = simulate_consul(updates)    print("=== 30 次键变更时三个服务的连接/重连成本 ===")    print("etcd      : 连接数=%d, 消息数=%d, 重连数=%d" % etcd)    print("zookeeper : 连接数=%d, 消息数=%d, 重连数=%d" % zk)    print("consul    : 连接数=%d, 消息数=%d, 重连数=%d" % consul)  if __name__ == "__main__":    main()

目的：模拟同一批客户端监听 30 次键变更时，etcd 流式 watch、ZooKeeper 一次性 watch、Consul 阻塞查询三者在连接数、消息数、重连次数上的差异，直观验证正文结论。

def simulate_etcd(updates, clients=3):模拟流式 watch，每个客户端只建立一条长连接
connections = clients连接数固定为客户端数，不随更新次数增长
for _ in range(updates):模拟逐次键变更事件
connections += 1ZooKeeper 每次事件触发后都要重新注册监听，连接成本线性增长
polls = updates // poll_interval + 1Consul 采用区块查询，请求次数约为更新数除以轮询间隔
if __name__ == "__main__":保证脚本既可以作为模块导入，也可以直接运行

常见误区

误区我想着 ZooKeeper 里注册一次监听，以后数据变了它就会一直告诉我，像微信消息一样实时推送。

正解经典 ZooKeeper watch 是一次性的：事件触发后监听立即失效，下一轮变更必须重新注册。etcd v3 的 watch 才是真正意义上的长连接流式推送。两者在“推送持续性”上存在本质差异，高并发场景下 ZooKeeper 的反复注册会放大网络开销。

为何常见：很多教程只讲“watcher 能在节点变化时收到通知”，省略了“只通知一次”这个关键细节，导致初学者把两种机制混为一谈。

误区ZooKeeper 有树形目录，能做复杂协调；etcd 只有一个扁平的 key-value，肯定做不了分布式锁和选举。

正解KV + 前缀查询在工程上比树形更灵活。etcd 支持租约、事务、前缀 watch，完全覆盖锁与选举场景；ZooKeeper 树形层级虽然直观，但每个 znode 数据量有限，路径越深操作越重。能力高下不在存储形态，而在事务与通知语义。

为何常见：误以为存储模型的复杂度等于能力上限，忽略了整体语义设计才是协调服务的关键。

误区两者都提供键值存储，API 看起来也差不多，把 etcd 地址改成 Consul 不就行了？

正解Consul 的重点在服务目录和健康检查，KV 只是辅助设施；etcd 则把 KV 的 watch、事务、租约打磨成核心能力。替换时锁实现、watch 语义、版本号行为都不完全对齐，必须重写客户端逻辑，不能简单改地址。

为何常见：只看到表层 KV 接口，忽略了数据模型与配套生态的差异。

误区etcd 和 Consul 用 Raft，ZooKeeper 的 ZAB 也类似，反正都是投票选主，集群表现应该差不多。

正解ZAB 在广播前有发现 + 同步阶段，用 zxid 做全局严格排序；Raft 以任期（term）和日志索引为主线。两者都保证线性一致，但选主期间的可用性、日志复制的开销、读放大的表现都不同。协议细节决定了故障恢复的速度和极端情况下的行为。

为何常见：把“共识机制”当作黑盒，忽视协议差异在真实故障中造成的不同表现。

误区加锁就是 setnx + 过期时间，三个组件都不用选，Redis 更快。

正解setnx 锁存在主从切换丢锁、锁续租复杂等问题。etcd 和 ZooKeeper 通过租约、版本号、临时节点提供强一致锁语义，配合 fencing token 避免锁被误删。若业务要求绝对安全，协调服务仍然是更可靠的选择。

为何常见：业务简单时 Redis 锁够用，但没考虑到故障窗口和数据安全边界，直到出现重复消费才后悔。

面试题

Q1. etcd 使用的共识算法是什么？

单选题 · easy

A.Paxos
B.Raft← 正确答案
C.ZAB
D.PBFT

答案：B。etcd 使用的核心算法是 Raft。Paxos 是理论共识算法，ZAB 是 ZooKeeper 的共识协议，PBFT 是拜占庭容错算法，因此只有 B 正确。

Q2. ZooKeeper 集群要求超过一半节点确认写入，这种机制被称为？

单选题 · easy

A.两阶段提交
B.多数派选举← 正确答案
C.读写分离
D.幂等写入

答案：B。ZooKeeper 通过多数派确认来提交事务，这就是多数派选举（法定多数）机制。两阶段提交是数据库分布式事务协议，与 ZooKeeper 的核心提交模型不同。

Q3. 下列关于 ZooKeeper 经典 Watch 机制描述正确的是？

单选题 · mid

A.事件触发后自动重新注册
B.事件触发一次后失效，需重新注册← 正确答案
C.采用长连接流式推送
D.不做任何事件通知

答案：B。经典 ZooKeeper watch 是一次性的，触发一次后立即失效，客户端必须手动重新注册。流式推送是 etcd v3 的特性，因此选 B。

Q4. etcd v3 的 Watch 与 ZooKeeper Watch 的最大区别是？

单选题 · mid

A.两者都走 HTTP 轮询
B.前缀流式监听对比一次性通知← 正确答案
C.均使用 Kafka 中转消息
D.均不支持历史事件回放

答案：B。etcd v3 支持前缀范围的流式监听，并可基于 revision 回放历史；ZooKeeper 经典 watch 是单次通知且不能回放。因此选 B。

Q5. Consul 与 etcd 在服务发现上的核心差异是？

单选题 · mid

A.内置健康检查与目录能力← 正确答案
B.内置 DNS 服务发现能力
C.不支持跨数据中心部署
D.无法提供 HTTP 协议接口

答案：A。Consul 原生内置健康检查和服务目录，etcd 需要自行实现健康检查逻辑。B 也是 Consul 的能力但不是核心差异方向；C 和 D 与事实相反。

Q6. ZooKeeper 使用 zxid 的主要作用是？

单选题 · hard

A.记录客户端会话超时
B.全局严格排序事务← 正确答案
C.标记节点创建时间
D.控制网络并发连接数

答案：B。zxid（ZooKeeper Transaction ID）是事务编号，用于全局严格排序，保证所有节点按相同顺序执行写入。它与会话超时、节点时间、连接数无关。

Q7. 在 etcd 中，利用事务 + 租约实现分布式锁时，为什么还需要 revision 比较？

单选题 · extreme

A.防止锁被误删除← 正确答案
B.提高写入吞吐量
C.保证日志压缩
D.降低 leader 选举延迟

答案：A。持有锁的客户端释放锁前，必须确认当前键的 revision 仍是自己写入的版本，否则可能删除后来者重新创建的锁。这一比较操作防止锁被误删除，是安全释放的关键，与吞吐量、日志压缩、选举延迟无关。

Q8. 以下哪些是分布式协调服务的典型功能？

多选题 · easy

A.服务发现← 正确答案
B.配置管理← 正确答案
C.分布式锁← 正确答案
D.关系型查询

答案：ABC。etcd、ZooKeeper、Consul 三大核心能力是服务发现、配置管理和分布式锁。关系型查询属于数据库职责，协调服务不提供 SQL 能力。

Q9. 关于三者的数据模型，哪些描述正确？

多选题 · mid

A.etcd 使用扁平键值存储← 正确答案
B.ZooKeeper 使用树形 znode← 正确答案
C.Consul 在 KV 之上构建服务目录← 正确答案
D.三者都支持 SQL 查询

答案：ABC。etcd 是扁平 KV，ZooKeeper 是树形节点，Consul 在 KV 之上构建了服务目录与健康检查。三者都不提供 SQL 查询，D 错误。

Q10. 生产环境选型时，哪些因素应当优先考虑？

多选题 · hard

A.业务需要强一致配置存储，选 etcd← 正确答案
B.大数据生态兼容优先，选 ZooKeeper← 正确答案
C.多数据中心服务发现，选 Consul← 正确答案
D.单机高吞吐尽量选 ZooKeeper

答案：ABC。etcd 适合强一致配置存储，ZooKeeper 是大数据生态的标准底座，Consul 擅长多数据中心服务发现。ZooKeeper 并非单机高吞吐方案，它的优势在于协调语义而非吞吐，D 错误。