3. 单集群容量模型：etcd 的容量限制

etcd 单集群的容量并非无限。默认 2GB 的存储上限、key-value 的存储模型以及 MVCC 版本号机制，共同构成了容量评估的核心约束。理解这三者之间的相互作用，是进行多集群水位规划的前提。

3.1 默认 2GB 限制与背后的设计考量

etcd v3 默认将集群总数据量限制在 2GB（可通过 --quota-backend-bytes 调整，最大建议 8GB）。这一限制并非随意设定，而是基于以下三个关键因素：

• Raft 快照性能：当 Leader 向 Follower 发送快照时，2GB 的数据量在千兆网络下约需 20-30 秒完成传输。超过此值，快照传输时间过长，容易触发心跳超时，导致集群不稳定。
• 内存映射开销：etcd 使用 mmap 将后端 boltdb 文件映射到进程地址空间。2GB 的数据库文件会占用约 2GB 的虚拟内存，加上进程自身堆栈，对 4GB 内存的节点构成较大压力。
• 压缩与碎片整理：历史版本压缩（Compaction）和碎片整理（Defrag）操作在超过 2GB 的数据集上耗时显著增加，可能阻塞读写请求。

3.2 key-value 存储模型与容量占用

etcd v3 的存储模型是 扁平化的 key-value 结构，所有数据存储在一个 boltdb 桶（Bucket）中。每个 key-value 对的实际磁盘占用远大于其逻辑大小。

容量估算公式：

实际磁盘占用 ≈ (key_size + value_size + 8) × 版本数 × 1.4（boltdb 膨胀系数）

例如：一个 64B key + 1KB value 的条目，若保留 5 个历史版本，其磁盘占用约为：

(64 + 1024 + 8) × 5 × 1.4 ≈ 7.7 KB

这意味着 100 万个这样的 key，即使只保留最新版本，也需要约 1.5GB 的存储空间。

3.3 版本号与历史记录对容量的放大效应

etcd 采用 MVCC（多版本并发控制），每次对 key 的写入（Put）都会生成一个新的版本（Revision），旧版本不会被立即删除。这导致容量消耗与写入频率和版本保留数量直接相关。

版本堆积对容量的影响可通过以下场景说明：

• 高频更新场景：一个 key 每秒更新 10 次，1 小时后产生 36,000 个版本。若每个版本 1KB，仅此一个 key 就占用 36MB 磁盘空间。
• 批量写入场景：一次性写入 10,000 个 key，每个 key 更新 100 次，总版本数达到 1,000,000 个。若未及时压缩，存储量可能膨胀 10 倍以上。
• 删除与 TTL 场景：使用 --auto-compaction-retention 保留最近 1 小时的版本，但若写入速率高，1 小时内产生的版本数可能超过 100 万，导致存储快速上涨。

3.4 容量模型的核心公式与水位评估

综合以上因素，单集群的容量模型可归纳为以下公式：

总存储占用 = (当前活跃数据量) + (历史版本数据量) + (boltdb 元数据开销)

其中：
  活跃数据量 = Σ(key_size_i + value_size_i + 8)  for i in 所有活跃 key
  历史版本数据量 = Σ(key_size_i + value_size_i + 8) × (保留版本数 - 1)  for i in 所有被修改过的 key
  boltdb 元数据开销 ≈ 总数据量 × 0.3 ~ 0.5

水位评估阈值：

3.5 容量评估的常见误区

• 误区一：只看 key 数量 —— 忽略 value 大小和版本数。100 万个 1KB 的 key 加上 5 个版本，存储量可达 7GB 以上，远超 2GB 限制。
• 误区二：认为删除操作释放空间 —— etcd 的删除只是标记，实际空间直到压缩（Compaction）和碎片整理（Defrag）后才释放。
• 误区三：压缩后容量立即下降 —— 压缩仅标记旧版本为可回收，磁盘空间不会立即减少，必须执行 etcdctl defrag 才能回收。
• 误区四：忽略 watch 对版本的影响 —— 大量 watch 客户端会阻止旧版本的压缩，导致版本堆积无法清理。