2026 etcd与ZooKeeper集群服务器怎么配：法定人数、fsync延迟与跨机房的现实

为了高可用把三个节点拆到两个机房，听起来稳妥。真等机房间链路抖一次，整个集群反而一个字都写不进去——不是变慢，是明确拒绝写入。问题不出在节点数量，出在法定人数被摆错了位置：三个节点的 etcd 要两个节点达成一致才能提交，ZooKeeper 一样。你把节点摆成 2+1，占有两个节点的那侧机房一旦失联，剩下那个节点凑不出多数派，它只能停止服务。同机房三个节点至少还能扛住一台机器宕机。所以这类事故的根因从来不是机器不够多，而是故障域和票数在规划阶段就没对齐。

三个节点分到两个机房，可用性为什么反而掉了

可用性要拆成两件事来算

一件事是故障会不会发生，另一件事是故障发生后还剩几个节点能互相说话。一致性组件的可用性只取决于后者：集群里是否还存在一个包含多数派的连通子集。只要有，写入继续；只要没有，写入立刻停。

拿 2+1 这个摆法逐个数一遍。两个节点的机房里任意一台宕机，剩 1+1=2 票，集群照常工作，这一点 2+1 和三节点同机房没区别。可一旦承载两个节点的那个机房整体失联——光缆中断、核心交换机故障、机房侧电力问题、运营商侧割接——只剩 1 票，法定人数是 2，集群直接失写。也就是说，2+1 把"机房级故障"从一个本可接受的共同故障域，变成了必然击穿法定人数的单点。

有人会说，那我把两个节点的机房做得更可靠不就行了。方向反了：机房可靠性靠堆叠设备提升的空间有限，而法定人数是硬约束，与你花多少钱无关。真正想要机房级容灾，得让每个机房都握不到足以否决的票。

一个经常被误判的信号：能读不等于能写

失去法定人数之后，集群未必全瘫。部分读请求可能仍返回数据，进程端口还在，健康检查的 TCP 探活也通。上层如果只用探活判断健康度，告警会晚几分钟甚至十几分钟才响，这段时间里业务其实已经写不进去了。判断健康度要用一次真实写入或者带读一致性校验的请求，别只看端口。

先列故障域，再决定节点摆在哪

比较稳的做法是先写一张故障域清单：单台服务器、一个机柜、一列 PDU、一台接入交换机、一个机房、一座城市、一家运营商，逐个问一句"这个域整体失效后我还剩几票"。写完你会发现，很多团队嘴上说要机房级容灾，实际能接受的只是单机故障，那三节点同机房就够了，没必要去背跨机房的延迟成本。

法定人数这件事，决定了奇数节点不是讲究而是数学

法定人数的公式是 n/2 向下取整再加 1。三节点要 2 票，四节点要 3 票，五节点要 3 票，六节点要 4 票。把容忍能力和票数一起看，结论就很直白：四节点和三节点一样，都只能容忍一个节点失效，但四节点要求三票，任意时刻至少要三台机器同时健康，故障概率反而更高，成本也更高。偶数节点在这里没有任何收益，它只是把容错能力没提升的那部分，换成了更苛刻的达成条件。

五节点能容忍两个节点失效，代价是每次写入要等三票，跨机房场景里这个代价会被 RTT 放大，所以别默认"节点越多越稳"。在节点失效相互独立的假设下，四节点里至少两台同时故障的概率高于三节点，多买一台机器换来更低的可用性，这是很多人初次算完会觉得意外的地方。

ZooKeeper 的 observer 和 etcd 的 learner 都不参与投票，可以承担读扩展、就近读取或作为新节点追赶数据的过渡态，但不改变法定人数。想靠加 observer 提升写可用性是无效的，它只影响读。

写入路径上发生了什么：一次提交要等几次落盘

以 etcd 为例，客户端的一次写请求落到 leader 之后：leader 给这条记录分配 term 和 index，追加进本地 WAL，调用 fdatasync 把日志刷到盘上；随后并行把条目发给所有 follower；每个 follower 追加 WAL、刷盘、回 ack；leader 数到多数派 ack 之后才标记已提交，把它应用到后端 bbolt 状态机，最后向客户端返回成功。

摊开看，一次提交在返回之前至少要等两次物理落盘：leader 自己的那次 fsync，以及多数派 follower 的那次 fsync，而 follower 的耗时是"网络 RTT + 对端 fsync"。所以一次写入的延迟等于这些路径里最慢的那一次 fsync，不是平均值，也不是最快的那台机器。把节点往远处放，等于主动把 RTT 加进每次提交的关键路径。

ZooKeeper 的形态类似：leader 生成 proposal，写事务日志并刷盘，follower 收到后写日志回 ack，多数派确认后发 commit，follower 才把变更落到内存里的 DataTree。它同样受"最慢那次落盘"约束，也同样受 RTT 约束。差别在细节：ZooKeeper 的事务日志和快照目录可以分开配置，etcd 则是 WAL 与后端 db 两个文件。

写放大藏在状态机里

WAL 是顺序追加，看起来对磁盘很友好，但状态机那一层不是。bbolt 用写时复制提交事务，改动几百字节的 value 可能需要重写整页并连带更新父页，一次逻辑写被放大成多次物理页写，再叠加压缩与碎片整理的额外写入，落盘数据量远大于业务写入量。这也是评估磁盘要看小随机写延迟稳定性的原因。

fsync 延迟才是隐藏的性能天花板

看磁盘只看平均延迟会被骗。均值 1 毫秒、p99 50 毫秒的盘，在 raft 里意味着每百次提交就有一次要等 50 毫秒以上，上层看到的往往就是 p99 写超时报警。一致性组件对延迟长尾极其敏感，因为每笔写入都要等最慢那次落盘。

长尾通常来自这几处：消费级固态的 SLC 缓存写满后掉速，主控垃圾回收时延迟抬升；没有掉电保护的盘 fsync 行为更保守；网络块存储的一次 fsync 还叠了一次网络往返，后端负载波动直接传导；以及共享盘争抢——数据目录若和容器镜像层、业务日志、系统盘挤在同一块盘上，别人的一次大 IO 就变成你的提交延迟。

测量可以直接用 fio 官方手册里的同步写写法，ioengine 设为 sync、fdatasync 设为 1，模拟每次写入都强制刷盘，跑几分钟取 p99 而不是平均值。etcd 官方的硬件建议文档也把这种测法作为磁盘评估入口。跑之前先停掉同盘上的其他写入，否则你测的是邻居的负载。

坑：用普通 SATA 固态扛 fsync，写入延迟抖动大

问题。集群平时正常，每隔一段时间出现一批写超时，持续几秒到几十秒后自行恢复，磁盘平均使用率并不高。

为什么发生。普通固态在缓存耗尽、垃圾回收启动或写放大累积到一定程度时，fsync 延迟会突然抬升一个数量级。平均使用率看不出来，因为抖动短时且集中在队列深处。

怎么判断。用同步写加压方式测 p99 与 p999，看是否出现远超均值的尖峰；同时看 WAL fsync 耗时分位与后端提交耗时分位是否同步抬升——两个一起抬，基本锁定在磁盘而不是网络。

怎么规避。数据目录换成企业级固态并独占一块盘，不与系统盘、镜像层、日志共用；WAL 和数据目录单独挂载；把延迟分位而不是使用率纳入日常监控。

fsync 慢会连带影响选主

还有一条容易被忽略的传导链：follower 的 fsync 变慢，ack 就变慢，leader 迟迟收不到多数派确认，请求堆积；慢到心跳处理也被拖住时，follower 会认为 leader 失联并转而发起选举。一次磁盘抖动就这样变成任期切换，切换期间集群不可写。磁盘问题和网络问题在监控上的表现有时候很像，区分依据是看 fsync 分位和 peer RTT 分位哪一个先动。

RTT 怎么吃掉心跳与选举超时预算

etcd 的心跳间隔默认 100 毫秒，选举超时默认 1000 毫秒。官方调优文档给的经验关系是：心跳间隔大约取节点间往返时延，选举超时至少是往返时延的十倍。默认值按同机房亚毫秒级 RTT 设计，放到跨机房场景常常不够。

具体换算：同机房 RTT 常在 1 毫秒以内，默认参数绰绰有余；同城不同机房在 1 到 3 毫秒量级；跨城则可能到几十毫秒量级。按十倍规则，30 毫秒 RTT 需要选举超时不低于 300 毫秒，但真实网络有抖动和丢包重传，通常留到 1 到 2 秒。具体数值要用自己的网络实测，别照抄。

代价是故障切换变慢。切换时间大致等于检测时间加选举收敛时间，选举超时从 1 秒拉到 2 秒，一次 leader 故障的不可写窗口就从约 1 秒变成数秒。核心权衡就在这：超时调小，网络抖一下就误切换；超时调大，真故障恢复得慢。没有两头都占的设置，只能按你能接受多长的写入中断来定。

坑：心跳超时按默认值，跨机房场景直接雪崩

问题。集群频繁发生任期切换，每次切换伴随几秒不可写，业务侧表现为间歇性报错，网络监控上未必有明显中断。

为什么发生。默认的心跳与选举超时是按同机房网络设计的。跨机房 RTT 升高或出现丢包重传时，follower 在超时窗口内收不到心跳，就判定 leader 失效并发起选举，抖动持续则切换反复发生。

怎么判断。看任期切换计数在一小时内的增量，健康集群这个值应该长期为 0，一天出现几次就要查；再对比 peer RTT 的分位变化，若 RTT 抬升与切换时间点吻合，基本可以确认。

怎么规避。按实测 RTT 重设心跳间隔与选举超时，两者按约十倍的比例一起调；把任期切换次数做成告警项而不是事后排查项；跨机房链路尽量走稳定的高速线路或专用带宽，并为抖动预留余量，别按理想 RTT 卡边界。

ZooKeeper 侧对应的几个参数

ZooKeeper 用 tickTime 作为时间单位，默认 2000 毫秒；initLimit 默认 10，表示 follower 与 leader 建立连接并完成同步的时限是 10 个 tick；syncLimit 默认 5，表示心跳与同步允许的最大延迟是 5 个 tick。节点跨机房部署时，若 RTT 高或抖动大，syncLimit 太紧会让 follower 被反复判定为落后而断开重连，表现为成员列表不停变化。这类场景通常要上调 syncLimit 与 initLimit，并把 tickTime 一并考虑进去，因为两者的实际时长是乘法关系。

磁盘怎么选：随机写、写放大与寿命

随机写才是压力来源

WAL 的顺序追加对介质友好，真正吃 IOPS 的是状态机的随机小页写入，以及压缩、碎片整理带来的额外写，所以选型看的是小随机写下的延迟稳定性而非顺序带宽。文件系统建议 ext4 或 xfs，挂载加 noatime；一致性组件对延迟敏感，交换分区倾向要调低甚至关闭。目录也建议分离：etcd 的 WAL 与数据目录分别挂盘，ZooKeeper 的事务日志与快照目录分开，顺序写流和随机写流混在一块盘上会互相破坏对方的长尾。

三节点的钱大致花在哪

一致性组件本身对 CPU 和内存要求不高，钱主要花在三台机器的规格、数据盘介质，以及机柜与链路上。以一万网络（朗玥科技旗下）深耕 IDC 19 年（成立于 2007 年）的公开产品口径看，小规模验证环境可以用一万云 ¥25 起的小规格，三台就能把选主、故障切换、扩容流程完整跑一遍；生产环境从裸金属 E5-2620 32G/1T ¥999/月 这一档起步，对主频和 IO 有更高要求的可以上 E5-2698v4×2 32G/1T ¥3999/月 的档位，海外节点另有买 1 送 1 活动。这些是官网标价，实际以官网实时价为准。数据盘升级 NVMe、独享 IO、跨机房机柜与链路这类没有公开标准价的项，一律需询价，以官方实时报价为准。

付款方式上，通用年付相比月付通常能省一到两个月，折算约 83 到 92 折，属预估值，实际以下单核算为准。集群规模还没定下来时，先用小规格把 fsync 实测跑通再决定扩容。

快照、压缩与 db 大小：容量怎么估

etcd 的每一次写入都产生一个新的 revision，历史版本不会自动消失。自动压缩按保留时长回收旧版本，启动参数里可指定保留多少小时；但压缩释放出来的空间在后端文件层面通常不会立刻收缩，需要执行一次碎片整理才会真正变小。碎片整理会阻塞请求并带来 IO 尖峰，实践中要先切走 leader 再对 follower 逐个做。

配额是这条链上最容易被忘的一环。后端 db 的配额有默认值，超出后集群触发告警并转为只读，写入全部失败，且不会自动解除，需人工压缩、整理并解除告警。所以配额不是可选配置，它决定"磁盘被写满"这件事是被提前拦住还是直接把集群打挂。

容量粗算的方式是：键的平均大小乘以键的总数得到基础占用，再乘以历史版本留存带来的膨胀倍数（通常在几倍量级，取决于压缩保留时长与写入频率），最后加页对齐与空闲页开销。假设场景：五十万个键、平均键值 1KB、保留一小时历史，基础占用约 0.5GB，叠加膨胀与页开销后落在 2 到 4GB 只是粗估，真实数字要按自己的写入模式跑几天实测。配额建议按实测结果的数倍来设，留足压缩与整理的缓冲。

坑：db 大小不设配额，磁盘被写满导致集群只读

问题。集群突然不可写，日志出现空间不足告警，磁盘使用率接近百分之百，但业务侧没有明显写入量上涨。

为什么发生。历史版本持续累积，压缩保留时长设得过长或者根本没开，db 文件只增不减；碎片整理长期没做，空闲页也一直占着空间。盘满后，一致性组件为保护数据一致性会主动转为只读。

怎么判断。看后端 db 大小与配额的比值曲线，长期单调上升且没有回落台阶，说明压缩或整理至少有一个没生效；再检查配额告警计数是否曾经出现。

怎么规避。显式设置配额并配告警，阈值设在配额七成左右就开始提醒；开启自动压缩并按业务能接受的历史回溯长度设保留时长；把周期性碎片整理写进运维手册，明确执行窗口与顺序。

坑：备份只做数据不做快照校验，恢复时才发现不可用

问题。定期备份一直在跑，出了事故去恢复，才发现快照文件损坏、版本不匹配或者根本不完整。

为什么发生。备份脚本只负责生成文件，没有校验环节。生成过程中集群状态异常、磁盘写满、版本升级导致格式变化，都会产出一份看起来正常却恢复不了的文件。

怎么判断。看有没有校验记录与恢复演练记录。从来没有真正恢复过一次的备份，等于没有备份。

怎么规避。每次快照生成后做校验和记录并留存；定期把快照恢复到独立环境，起集群、读关键键、比对条数，把恢复演练做成例行任务。

几种节点分布方案的真实差异

把这张表按"能容忍什么"排个序，规律很清楚：想要机房级容灾，就必须让每个机房的票数都不足以否决，这天然要求三个机房或更多投票节点；想要低延迟，就别把投票节点拉远，异地只读副本交给 learner 或 observer。两个机房三个节点想同时拿到机房级容灾和低延迟，数学上不成立。

监控要看什么：提交延迟、任期切换、落后节点

监控项不用铺很多，抓住三类就够了。落盘耗时：WAL fsync 耗时分位、后端提交耗时分位，前者长说明磁盘或共享 IO 有问题，后者长说明状态机写入或整理压力大。网络与任期：节点间往返时延分位、任期切换累计次数、当前是否有 leader。容量与告警：后端 db 大小、配额使用率、空间不足类告警计数、慢应用与慢读索引计数。

任期切换是这里面信息密度最高的一个。健康的集群这个值长期不动，一旦一小时里出现几次，说明有节点在怀疑 leader，原因不是网络抖就是落盘慢。

落后节点要看"相对"而不是"绝对"。单个 follower 的 WAL fsync 分位明显高于其他节点，或者它到 leader 的往返时延偏高，它就可能在某次抖动里成为拖慢提交的关键路径。ZooKeeper 侧看 follower 同步数与待同步队列长度，队列长期不为零说明有节点追不上。

阈值给个经验起点：WAL fsync 的 p99 在 10 毫秒量级以内算正常，接近或超过 100 毫秒就很危险；后端提交 p99 超过 25 毫秒值得关注；db 大小达到配额七成开始提醒。这些只是起点，真正要用的是自己跑出来的基线，把告警设在基线的偏离上，而不是抄别人的数字。

扩容与替换节点的操作顺序

三节点集群里换掉一台机器，最容易出事的地方是顺序。错误做法是先加新节点、再删旧节点——中间会短暂变成四个成员，法定人数变成 3，此时任何一台再出问题就直接失写；而且新节点加入时要从 leader 拉全量快照，数据量大时会给正在服务的集群带来额外压力。

更稳的顺序是：先移除故障成员，让集群回到三个成员、法定人数 2 的状态，再加入新成员。新成员建议以 learner 身份加入，先追数据，确认追平后再提升为投票成员。etcd 从 3.4 版本开始支持 learner，这个机制正是为了避开"新节点边追赶边影响提交"的问题。整个过程一次只动一个成员，动完确认健康再动下一个。

从三节点扩到五节点同理，一次加一个。中间的四成员状态法定人数是 3，容错能力与三节点一样但达成条件更苛刻，所以要尽快补到第五个，别让集群长期停在偶数成员上。滚动重启同样一次一台，等它重新加入、同步追平、健康通过，再处理下一台。

还有两个实操细节。移除成员后若要复用原来的名字和地址重新加入，需先清理残留的成员信息与旧数据目录，否则会因成员 ID 冲突或数据目录里的旧集群信息而启动失败。另外，成员变更本身也要经过共识，集群已经失去法定人数时，正常成员变更命令救不回来，只能走从快照恢复的路子——这又回到前面那条备份校验的重要性。

从交付角度看，替换节点的耗时很大一部分不在软件操作，而在新机器何时到位、装好系统并接入网络。一万网络（朗玥科技旗下）深耕 IDC 19 年（成立于 2007 年），在华南、华东、华北、中国香港以及海外多个节点有标准化交付能力，自营机柜最快 1 分钟上架，硬件故障 10 分钟自动迁移，7×24 中文工单 5 分钟响应。节点同规格补齐、跨节点批量开通若能在小时级完成，扩容演练才敢真的做，而不是一直停留在文档里。

一致性集群的验收与演练

验收不要只看"三台起来了、能读能写"。真正要拿到手的是四个数字：一次 follower 故障的写入中断时长、一次 leader 故障的切换完成时长、故障期间的写入失败率、从快照恢复到可用集群的耗时。前两个决定上层重试策略怎么配，后两个决定恢复目标能不能兑现。

演练清单可以按下面几条排，每季度跑一轮，或每次调整节点分布、更换磁盘、升级版本后补一轮。

• 网络注入：用丢包与延迟注入工具模拟机房间抖动，观察任期切换次数与写入失败时长，验证超时参数余量是否够。
• leader 强制下线：停掉 leader 进程，记录从停止到新 leader 产生、写入恢复的完整耗时。
• 磁盘加压：用同步写压测把 fsync 延迟打上去，观察提交延迟分位与任期是否稳定。
• 配额打满：在演练集群上把配额设小，确认告警是否触发、是否按预期转为只读、解除流程是否走得通。
• 快照恢复：把最近快照恢复到全新环境，起集群、比对关键键与总条数，确认备份真能用。
• 成员变更演练：走一遍 learner 加入、追平、提升、移除旧成员，记录每步耗时与集群健康状态。

最后回到那个判断。规划一致性集群的正确顺序是反过来的：先明确要容忍哪个层级的故障——单机、单机柜、单机房还是单城市——再反推需要几个投票节点、摆在哪几个故障域，最后才根据法定人数带来的票数去定磁盘和网络要求。节点分散本身不产生可用性，它只是把故障域换了个位置；换完之后多数派若仍依赖某一个故障域，这次分散不但没收益，还额外付了一次 RTT 的代价。把 fsync 的 p99 和节点间 RTT 测出来，这两个数字加上故障域清单，答案基本就自己出来了。

关于节点数、磁盘与超时的几个具体问题

三个节点能不能放在两个机房？

技术上能起，收益却是负的。三节点法定人数是 2，摆成 2+1 时，承载两个节点的机房一旦整体失联，剩下的 1 个节点凑不出多数派，集群直接失写。这个摆法对机房级故障的容忍度是零，却让每次提交都背上跨机房 RTT。如果要求只是扛住单台服务器故障，三节点放同一个机房更稳也更快；如果要求扛住整个机房失效，那至少三个机房各放一个投票节点，让任何单一机房都拿不到否决票。

etcd 一定要固态硬盘吗？

生产环境基本可以当作硬性要求。raft 每次提交都要等多数派节点完成一次 fsync，机械盘的随机写延迟在数十毫秒量级，会直接把提交延迟和选举稳定性拖垮。固态里也要分档次：企业级盘在长尾控制、掉电保护上明显优于消费级。选型别看顺序写带宽，用同步写的方式测 p99 与 p999，并让数据目录独占一块盘。

心跳和选举超时怎么设？

etcd 默认心跳间隔 100 毫秒、选举超时 1000 毫秒，这个组合是按同机房亚毫秒级 RTT 设计的。官方调优文档给的经验关系是心跳间隔约等于节点间往返时延，选举超时至少是往返时延的十倍。跨机房部署先实测 RTT，再按这个比例一起调，不能只动一个。调到多大取决于业务能接受多长的写入中断：超时越大，误切换越少，但真实故障的恢复窗口越长。同时把任期切换次数做成告警，健康集群这个值应该长期为 0。

节点数为什么是奇数？

因为法定人数是过半数。三节点要 2 票、四节点要 3 票，两者都只能容忍一个节点失效，但四节点每次写入要多等一票，任意时刻需要健康的机器更多，故障概率反而更高。偶数节点没有换来任何额外容错能力，只是提高了达成共识的门槛。五节点能容忍两个节点失效，代价是每次提交要等三票，跨机房场景里这个代价会被 RTT 放大，所以也不是越多越好。

磁盘要多大？

先估 db 大小：键的平均大小乘以键总数得到基础占用，再乘以历史版本留存带来的膨胀倍数，最后加页对齐与空闲页开销；压缩保留时长越长、写入越频繁，膨胀倍数越高。配额要显式设置并留出数倍余量，因为配额耗尽会让集群转为只读且不自动恢复。磁盘容量在配额基础上再留一截，给碎片整理的临时空间和快照文件留位置。碎片整理不会自动收缩文件，需定期执行且有 IO 尖峰，要安排在低峰期并先切走 leader。

跨城部署可行吗？

可行，但要清楚代价。跨城 RTT 常在数十毫秒量级，raft 每笔写入都要等多数派落盘，这笔 RTT 会直接进入每次提交的关键路径，吞吐和延迟都会明显劣化；同时选举超时必须同步放大，故障切换的不可写窗口从约 1 秒拉到数秒。业务写入量低、能接受秒级中断时可以接受；写入密集或要求亚秒级切换，就不建议把投票节点跨城放，改为同城三机房承载投票，跨城只放 learner 或 observer 做只读副本与灾备。

ZooKeeper 和 etcd 选型怎么想？

两者的共识机制都要求多数派确认，也都要在返回前落盘，物理约束是同一套：法定人数、最慢那次 fsync、节点间 RTT。差异在工程细节：ZooKeeper 的事务日志与快照目录可分开配置，时间参数以 tick 为单位，靠 initLimit 与 syncLimit 控制同步与心跳时限，跨机房时这两个值容易偏紧；etcd 用 WAL 加后端 db 两个文件，用心跳间隔与选举超时两个绝对时长参数，并支持 learner 做无投票过渡。如果底座已选定，优先把选型问题换成参数问题——换组件解决不了法定人数和磁盘带来的约束。

本篇数据来源与口径说明

etcd 官方文档（Raft 共识流程、硬件建议与磁盘评估方法、心跳与选举超时调优、运行时重配置与 learner 机制）；Apache ZooKeeper 官方 Administrator's Guide（事务日志与快照目录配置、tickTime / initLimit / syncLimit 参数含义、自动清理配置）；Raft 论文《In Search of an Understandable Consensus Algorithm》；fio 官方手册（同步写与 fdatasync 测量方式）；bbolt 项目文档（写时复制事务与页管理）。

一万网络官网价目与节点说明 https://www.idc10000.net/（裸金属、一万云及多节点产品公开标价、服务响应与快照能力说明）。文中引用价格为官网标价，实际以官网实时价为准；未公开标准价的机柜链路、数据盘升级等项标注为需询价。年付折扣为预估值，实际以下单核算为准。

文中延迟量级、容量估算与告警阈值均为基于公开文档与常见部署逻辑的经验区间，未经实测对比，真实数值需按自身硬件、网络与写入模式实测确认。