京公网安备11010502063487号一个父节点下放几万个子节点会怎样?这篇量 get_children 的延迟随子节点数的变化,再对比分层设计,最后看一个容易被忽略的事实:响应大小的限制其实在客户端。
子节点数 创建用时 s get_children ms 结果
1000 0.1 0.7 成功
10000 0.9 3.8 成功
20000 1.1 7.6 成功
25000 0.6 9.0 成功
30000 0.5 9.3 成功 创建用时 3.1 s;100 个父节点各 get_children 的中位延迟 0.24 ms、最大 0.30 ms 服务端 zk_znode_count = 60106
delete /shard000(有 300 个子节点)→ NotEmptyError kazoo delete(recursive=True) 删除 300 个子节点 + 父节点用时 844 ms
ls /big → WatchedEvent state:Disconnected type:None path:null zxid: -1 | 126 字符输出 加 -Djute.maxbuffer=4194304 后 ls /big → 输出 1260000 字符,开头 [child-000000000000000000000000000000000
这一节说明,是否「超过上限」要看是哪个客户端:服务端发出去的响应并没有被限制,是 Java 客户端读到超长的包时主动断开。选客户端库和排查「莫名断开」问题时要想到这一点。