章节摘要:Gossip 维护集群视图,一致性哈希 + vnode 决定数据落点,LSM(CommitLog → MemTable → SSTable → Compaction)支撑写优化路径。本章对照 HBase Region/ZK 与 Mongo 分片 chunk 迁移。
阅读完本章,你应当能够:
NetworkTopologyStrategy 与 Snitch存储引擎是「写优化换读放大」的契约——与 HBase HFile 同源 LSM,协调层却完全不同。
Phi 故障检测、Seed 节点、Snitch 与 rack 感知。
SimpleStrategy vs NTS、CL 罗盘、三层 repair。
CommitLog、MemTable flush、SSTable 归并读、STCS/LCS/TWCS。
Gossip(谁活着) → 复制(数据在哪) → LSM(如何持久化) ↓ CL 与 Read Repair

| 参数 | 默认值 | 含义 | 出错症状 |
|---|---|---|---|
num_tokens |
256 | 每节点 vnode 数 | 手动调 1 后扩缩容迁移风暴 |
gossip_interval |
1s | Gossip 交换周期 | 调大后故障发现变慢 |
phi_convict_threshold |
8 | Phi 故障判定阈值 | 调小误判宕机、调大漏判 |
hinted_handoff_enabled |
true | 写缓冲开关 | 关闭后短离线丢写 |
max_hint_window |
3h | hint 最长存活 | 超期节点需 repair |
gc_grace_seconds |
864000 | tombstone 保留期 | 未 repair 时删除复活 |
Gossip 为什么不搞一个中心注册表? 千节点集群里 ZK 会成为 CAP 瓶颈与运维单点;Gossip 用 O(log N) 轮次交换状态摘要,换来无中心视图。代价是视图短暂不一致,由数据平面的 CL 与 repair 兜底。
vnode 和物理节点是什么关系? vnode 是环上的逻辑 token 段,一个物理节点默认持 256 段。物理节点增减时数据在环上小步迁移,而不是旧版「一节点一环」的大范围移动。
MemTable 为什么放堆内? 因为要支持并发读写与按 key 有序访问,JVM 对象模型最直接;代价是 Young GC 频率高。堆外承担 Bloom Filter、Key Cache 等只读缓存。
Compaction 策略为什么不能一个全局默认走天下? 写密集、读敏感、时序 TTL 三种负载对「写放大 vs 读放大」的需求相反,STCS/LCS/TWCS 各占一角,只能表级选择。
| 术语 | 一句话定义 | 章节 |
|---|---|---|
| Phi 故障检测 | 按心跳分布计算置信度的自适应超时 | 2.1 |
| Seed | 新节点加入时的首个 Gossip 联系人 | 2.1 |
| Snitch | 把节点 IP 映射到 rack/DC 的探测器 | 2.1 |
| Token Ring | 2^64 哈希环,决定分区落点 | 2.1 |
| Replication Strategy | SimpleStrategy / NetworkTopologyStrategy | 2.2 |
| CommitLog | 顺序追加的崩溃恢复日志 | 2.3 |
| MemTable | 堆内有序写缓冲 | 2.3 |
| SSTable | 磁盘上不可变的有序文件 | 2.3 |
| Compaction | 多 SSTable 归并,控读放大 | 2.3 |
| Bloom Filter | 概率性过滤器,挡无关 SSTable IO | 2.3 |
# 用命令验证你对本章的理解 nodetool ring # 你能读出谁持有哪个 range 吗? nodetool gossipinfo # GENERATION 与 HEARTBEAT 代表什么?
能答出三问即可继续:其一,为什么 vnode 让均衡粒度更细;其二,QUORUM 写返回后读一定能看到吗,为什么;其三,LSM 用「读放大」换「写放大」,体现在哪个环节。