【etcd】bbolt 后端：mmap、batch 与单写者约束
内容提要
etcd v3.5.33将MVCC映射至bbolt，采用mmap预分配与批量提交（100ms或10000条）优化fsync。单写者约束使写路径串行，读路径并发。delete操作立即提交保证线性一致。bucket布局以revision为键，treeIndex管理逻辑映射。
延伸解读
单写者约束的工程含义
bbolt 同一时刻只允许一个写事务，etcd 的 apply 路径因此全局串行。这意味着即使 Raft 已并行复制日志，apply 到 bbolt 时仍要排队。试图用多线程 apply 绕过会与 quota、consistent index、Watch 顺序冲突。读路径则通过 ConcurrentReadTx 并发执行，与写路径互不阻塞。
batch 提交与 delete 的特殊处理
默认 100ms 或 10000 条 pending 触发批量 commit，以摊薄 fsync 开销。但 delete 操作会立即 commit，因为 delete 没有内存写缓冲，延迟提交可能导致读路径读到陈旧数据，破坏线性一致。这一设计权衡了写延迟与一致性，是理解 etcd 写性能的关键。
mmap 预分配与容量规划
Linux 下默认 InitialMmapSize 为 10 GiB，预映射大于潜在库文件，避免写者扩容时长时间阻塞读者。这要求运维规划容量时考虑 --quota-backend-bytes 与 mmap 预分配的配合。若库文件超过预映射，可能触发 remap，影响性能。
Q&A
etcd 的 bbolt 后端如何实现批量提交？
etcd 的 bbolt 后端通过 batchTxBuffered 聚合写操作，默认每 100ms 或累计 10000 条 pending 操作时触发一次批量 Commit()，以减少 fsync 次数。
为什么 etcd 的 delete 操作会立即提交事务？
因为 delete 操作没有内存写缓冲，若延迟提交，后续读可能从 bbolt 读到陈旧数据，破坏线性一致性。因此 delete 操作会立即 commit。
etcd 的 bbolt 后端如何实现并发读写？
bbolt 支持一个写事务与多个读事务并发。etcd 在此基础上封装了 BatchTx 用于写路径（串行），ConcurrentReadTx 用于读路径（并发），读路径通过复制 txReadBuffer 和引用当前 bbolt 读事务，实现非阻塞读。
etcd 的 bbolt 后端如何组织数据？
bbolt 使用 bucket 分区，主要 bucket 包括 key（以 revision 为 key，存储 mvccpb.KeyValue）、meta（元数据）、lease（租约）、alarm（告警）等。逻辑 key 通过内存 treeIndex 映射到 revision，再通过 revision 到 key bucket 获取数据。
etcd 的 bbolt 后端如何利用 mmap 优化读性能？
etcd 打开 bbolt 时设置 InitialMmapSize（默认 10 GiB），预映射大区域，避免频繁 remap。读路径通过 mmap 直接访问页缓存，减少 read 系统调用，提升范围读性能。
etcd 的 bbolt 后端如何保证线性一致性？
通过单写者约束和 delete 立即提交保证线性一致性。写路径串行，读路径并发，且 delete 操作立即 commit，避免读到陈旧数据。同时，ReadIndex 机制确保读在 applied index 对齐后进行。
