WiredTiger 存储引擎

4.1B-tree 与文档级并发

WiredTiger 给每个集合、每个索引各维护一棵 B-tree；并发写靠文档级乐观 MVCC，冲突即重试。

底层机制（比文档深一层）：WiredTiger 默认是行存 B-tree——每个集合一棵 B-tree、每个索引一棵 B-tree，各自是磁盘上一个独立文件。WiredTiger 也提供 LSM-tree 选项（type=lsm），但默认不开，因为 LSM 用读延迟换写吞吐，不适合 MongoDB 的通用读写画像。并发控制是文档级乐观 MVCC，不是锁：一次写入把版本化更新挂到 B-tree page 内存里的 update chain（一条 skip list）上，不就地改 page。两个并发事务改同一文档时，其中一个在提交期检测到冲突、抛出 WriteConflict，由 MongoDB 层自动 abort 并 retry。对照 Postgres：Postgres 是 MVCC-in-heap——新版本作为新元组追加进 heap、旧元组就地留在原页等 VACUUM 清理；写冲突走的是行级锁阻塞，后到的事务等锁释放，而不是被判败重来。机制点完全不同：一个是乐观重试，一个是悲观阻塞。

// 确认存储引擎与每集合的 B-tree 文件
db.serverStatus().storageEngine
// → { name: "wiredTiger", ... }

// 看某集合的 WiredTiger 细节：block-manager、btree、cache 占用
db.orders.stats().wiredTiger["block-manager"]
// 写冲突计数（高 = 多个写打在同一批文档上，触发乐观重试）
db.serverStatus().metrics.operation.writeConflicts

4.2MVCC 快照与 history store

每个操作看到一个时间戳确定的快照；旧文档版本被写进磁盘上的 history store。

底层机制（比文档深一层）：可见性由 transaction id + commit timestamp 决定——一个操作只看到 commit timestamp 不晚于自己快照点的版本。关键伏笔在这里：MongoDB 用 oplog 的 optime 驱动 WiredTiger 的 commit timestamp，让存储层的版本时间线和复制时间线对齐（05 章副本集会接上这条线）。eviction 把一个 page 写回磁盘时，若该 page 上挂着多个版本，最新值写进数据文件、旧版本写进 history store（磁盘上的一个独立表）。因此 MongoDB 没有 VACUUM——旧版本的回收发生在 eviction / checkpoint 的页重整（reconciliation）里：重整时引擎判断哪些旧版本已无任何活跃快照引用，就地丢弃。对照 Postgres：死元组留在原 heap 页，必须靠后台 VACUUM 进程扫描表把它们标记可重用、并推进 freeze；回收是一个独立的、需要调参（autovacuum 阈值）的后台任务。WiredTiger 把回收折叠进了本来就要做的刷盘动作，不再有单独的清扫扫描。

4.3cache 与 eviction：延迟悬崖

WiredTiger cache 默认约 (RAM−1GB) 的 50%，装大多未压缩页；填满到阈值后，应用线程被迫亲自参与 eviction 才能继续。

底层机制（比文档深一层）：WiredTiger cache 默认大小是 max(256MB, 50% × (RAM − 1GB))，缓存的是未压缩页——压缩只发生在磁盘上，进了 cache 就是解压后的形态，所以 cache 的有效容量按未压缩体积算。eviction 由专门的 eviction server + eviction worker 线程做近似 LRU，把页分成 clean / dirty / urgent 几个队列处理：clean 页直接丢，dirty 页要先写回磁盘（顺带做上一节的页重整）。引擎维持两道水位——eviction_target / eviction_dirty_target（后台开始干活）和 eviction_trigger / eviction_dirty_trigger（上限）。一旦越过 trigger 阈值，应用线程被"征召"同步参与 eviction——它得先帮引擎 evict 出空间，才能推进自己的读写。这是一道延迟悬崖（latency cliff）：不是后台默默降速，而是前台请求线程突然被拉去打工，p99 陡升。当 working set > cache，页会被反复换进换出（外加每次 miss 的磁盘读），形成持续 thrash。对照 Postgres shared_buffers：脏页由后台 bgwriter 和 checkpointer 刷，前台查询一般不被拉去刷盘（极端情况才会因 buffer 不足而等待）；缺页时走 OS page cache 兜底，行为更平滑。WiredTiger 把刷盘压力直接回灌到应用线程，所以过载表现更"硬"。

4.4持久性：checkpoint + journal

checkpoint 每约 60s 落一份一致快照，journal/WAL 覆盖两次 checkpoint 之间的窗口。

底层机制（比文档深一层）：checkpoint（默认约 60s 一次，或写满约 2GB journal 触发）把 cache 里的脏页刷成一份一致的磁盘快照；旧 checkpoint 在新 checkpoint 完整落盘之前一直有效——崩溃时可以回退到上一个完好的 checkpoint，不会读到写了一半的状态。journal/WAL 提供两次 checkpoint 之间的持久性：写操作先记 journal，引擎组提交（group commit）把一批 journal 攒在一起刷盘，默认约 100ms 一批（用 j:true 则该写同步等自己的 journal 落盘）。崩溃恢复 = 加载最后一个完好 checkpoint，再重放（replay）其后的 journal 到崩溃点。压缩方面：数据块默认 snappy（可选 zstd / zlib，更小但更慢），索引用前缀压缩（相邻 key 共享前缀）。对照 Postgres：checkpoint ≈ Postgres 的 checkpoint（也是落一致快照点），journal ≈ WAL（也是组提交、也是崩溃后从 checkpoint 重放）——这一层两者的形态最接近，区别更多在默认间隔和参数名。