6.2 羊群效应：一纸判决惊动满城听众

6.2 羊群效应：一纸判决惊动满城听众

本节摘要：羊群效应指单一节点变化触发大量客户端同时回调、同时重读、同时重注册，把通知流量放大成打向服务端的洪峰。本节用锁、注册中心、配置中心三个现场还原放大链路，给出"监听前序"与"监听收敛"两类解法及其参数。

案发现场：锁释放一次，集群抖一下

某调度平台用"全员监听队首节点"的方式实现了分布式锁（5.2 节的反面教材）。日终批量时段，锁每秒释放加获取约五十次，每次释放惊动排队中的八百个实例：八百个回调、八百次 getChildren、八百次重新注册监听。服务端的请求数在监控上竖起密集毛刺，zk_outstanding_requests 周期性冲高，普通配置读写延迟从 1 毫秒恶化到 80 毫秒——排队的人越吵，法庭越慢，业务越慢，吵得越凶，负循环成立。

放大链路的解剖

把这次洪峰逐帧拆开。一次锁释放（一个 delete）在服务端生成一个 NodeChildrenChanged 或 NodeDeleted 事件，事件本身毫不含糊。问题出在收方：八百个客户端各自的监听同时触发，回调里做的第一件事都是全量重读——getChildren 拉整个目录。八百次读在几十毫秒内挤进受理服务器，而其中七百九十九次读的结果是"我还是排不到"，于是七百九十九个客户端重新注册监听、继续等待。下一轮释放，同样的洪峰再来一遍。

流量的本质是通知扇出乘以无效重读：扇出系数等于监听者数量，无效重读比例接近百分之百（每次只有一人能获得锁）。监听者规模一到千级，哪怕单次事件毫厘，乘出来也是惊涛。

图：洪峰的形成与两道闸门

解法一：监听前序，锁场景的根治术

5.2 节迷你锁的核心一行就是解法本体：从排好的队列里找到自己的前序节点，只对它注册监听。锁释放只惊动一个人，扇出系数从"全体等待者"坍缩到 1。工程化时再补一层退避——前序节点删除后先重读再判断，而不是盲目 assume 轮到自己（可能恰好有新来者插到了更前面——顺序编号保证不会插队，但重读能把判断建立在事实上）。Curator 的 InterProcessMutex 内置这套逻辑，判别自己实现是否达标的标准只有一条：锁释放后，服务端请求数是否只增加常数笔。

解法二：监听收敛，订阅侧的合并术

注册中心与配置中心的监听是"应该广"的——每个消费者都需要知道名单变化。这里的洪峰来自高频变化乘以全员反应：批量发布时十台实例先后注册，名单抖十次，一百个消费者重建一百遍。解法是给订阅端加合并窗口：

// 收到事件不立即重建，压入待办并在窗口内合并
private final AtomicReference<ScheduledFuture<?>> pending = new AtomicReference<>();
private final ScheduledExecutorService timer = Executors.newSingleThreadScheduledExecutor();

registry.getListenable().addListener((c, evt) -> {
    if (evt.getType() != TreeCacheEvent.Type.NODE_ADDED
            && evt.getType() != TreeCacheEvent.Type.NODE_REMOVED) {
        return;
    }
    ScheduledFuture<?> old = pending.get();
    if (old != null && !old.isDone()) {
        return;                                  // 窗口内已有待办，合并
    }
    ScheduledFuture<?> task = timer.schedule(() -> {
        pending.set(null);
        loadFullList();                          // 窗口到期，全量重建一次
    }, 500, TimeUnit.MILLISECONDS);              // 合并窗口 500 毫秒
    pending.compareAndSet(old, task);
});
​

五百毫秒的合并窗口把十次抖动压成一次重建，代价是名单生效最多延迟半秒——对注册发现场景几乎无感。窗口取值经验：任务调度类取一百毫秒级，实例名单取五百毫秒到一秒；再长就要评估业务对生效延迟的真实容忍度了。

第三道闸：实在压不住时改数据形态

两个闸门都装上仍扛不住的场景，说明数据形态本身错了。典型信号：单个目录的子节点数过千、单节点监听者过千、变更频率与监听者数量的乘积长期上万。出路是拆分：注册中心按服务名分目录（每个消费者只订阅自己关心的服务，天然分流）；批量变更改用"版本节点"（变更者写一个版本号节点，订阅者只在版本变化时拉全量，扇出与变更频率解耦）。第七章 7.1 节会看到 Kafka 的分目录思路——同一思想的规模化版本。

要点回顾

• 洪峰公式：通知流量约等于事件频率乘以监听者数量乘以重读成本，三者任一归零即无事。
• 锁与选主治扇出：监听前序把"一人释放全员惊动"压缩成"一人释放一人接棒"。
• 订阅场景治重读：合并窗口把 N 次变更压成一次全量重建，代价是可接受的生效延迟。
• 改形态是终极解：分目录、版本节点，让扇出与变更频率解耦；压不住的负载本就不该放 ZK。

常见疑问

问：服务端有没有自我保护手段？ 有兜底没有根治：maxClientCnxns 限单机连接数，jute.maxbuffer 限报文大小，但这些都是防拖垮的保险丝，不是放大链路的解——解永远在客户端的实现方式上。

下一桩回到值班电话的两类高频报障：读到的数据怎么会旧，连接怎么老是超时。

把洪峰公式用在容量评估里

6.4 节的容量规划可以用本节的公式落到注册中心场景。设单服务平均实例数 n、订阅它的消费者数 c、实例变更频率 f（次每分钟），则注册中心的"事件乘积"约为 f 乘以 c。抽三个最大的服务代入：若乘积长期高于每分钟一万，应用级注册或分目录拆分必须提上日程；低于一千则现有结构可持续，不必预支复杂度。这个估算五分钟做完，比事后救火便宜得多。

延伸追问

问：合并窗口会不会造成"名单永远慢半拍"的体感？ 最多慢一个窗口。要紧的是把"名单生效延迟"与"调用失败重试"分开设计——延迟半秒正常，但重试逻辑要允许向旧名单实例发起的调用失败后立即换下一台。两者各司其职，体感就没有慢半拍。