【WiredTiger 内核】Cache · Eviction · Reconciliation · History Store · Checkpoint
内容提要
本文介绍WiredTiger内核系列文章，涵盖MongoDB默认引擎的MVCC实现路径，包括Cache、Eviction、Reconciliation、History Store和Checkpoint等核心机制。系列共17篇，从Session/Cursor到选型对照，重点解析更新链、脏页驱逐、旧快照读取及崩溃恢复，并对比PG、InnoDB、RocksDB等引擎，为运维和架构师提供完整技术参考。
延伸解读
阅读路径设计
系列按依赖关系组织，推荐从第1篇概览开始，再按需选择路径：核心路径（1→3→4→6→8→9→17）适合快速建立坐标系；MVCC/历史路径（7→8→11→16）适合从undo/堆版本过来的读者；持久化与恢复路径（9→10→11→15）面向运维。这种设计便于不同背景的读者按需深入。
版本锚定与实验纪律
文章明确锚定WiredTiger Architecture Guide（Version 12.0.0/develop）和MongoDB 8.0手册参数，并声明未实测不写跨引擎延迟排名。这种严谨性对技术文档尤为重要，读者可据此判断内容的时效性和可靠性，避免将未经验证的结论用于生产决策。
与相邻系列的对照价值
系列不仅覆盖WiredTiger自身，还明确与PostgreSQL、InnoDB、RocksDB等引擎的对照关系，并给出站内分工。对于架构师而言，这种跨引擎的机制对比有助于理解不同MVCC落点的优劣，但文章强调不写排名，读者需结合自身场景评估。
Q&A
WiredTiger 中旧版本数据存储在哪里？
WiredTiger 将旧版本数据存储在 History Store 中，对应的文件是 WiredTigerHS.wt。当用户表进行 reconciliation 或 eviction 时，旧版本会被写入 History Store，以便在页面被驱逐后仍能支持旧快照的读取。
WiredTiger 中脏页驱逐前必须执行什么操作？
脏页驱逐前必须执行 reconciliation（合并）操作。Reconciliation 会将内存页转换为磁盘镜像，并将最新已提交版本写入用户表，旧版本写入 History Store，然后才能安全地驱逐页面。
WiredTiger 的 checkpoint 和 journal 分别保证什么？
Checkpoint 提供跨文件的一致快照，并原子切换元数据，确保持久性；Journal（日志）则记录 checkpoint 之间的所有修改，用于崩溃恢复时重放操作，确保数据不丢失。
WiredTiger 中旧快照在页面被驱逐后如何还能读取？
当页面被驱逐时，reconciliation 会将旧版本写入 History Store（WiredTigerHS.wt）。后续读取旧快照时，如果所需版本不在用户表中，系统会从 History Store 中检索，从而保证旧快照的可读性。
WiredTiger 的 update chain 在 B-Tree 中如何工作？
在 WiredTiger 的 B-Tree 中，未提交的更新不会直接修改数据页，而是挂在 update chain 上。每次更新都会在链上追加新版本，直到事务提交或进行 reconciliation 时，最新已提交版本才会被写入用户表，旧版本则进入 History Store。
WiredTiger 与 InnoDB 在 MVCC 实现上有何不同？
WiredTiger 采用第三种 MVCC 落点：用户表只持久化最新已提交版本，旧版本存储在 History Store（WiredTigerHS.wt）中；而 InnoDB 使用 undo 日志来存储旧版本，属于“undo 旁路”方式。两者在旧版本存储位置和回收机制上存在差异。
WiredTiger 中 Rollback-to-Stable 的作用是什么？
Rollback-to-Stable（RTS）用于在崩溃恢复或回滚时，将数据库回滚到最后一个稳定点（stable timestamp）。它结合 stable、durable 和 oldest 时间戳来收束可见性，确保未提交或未持久化的更改被正确回滚。
WiredTiger 的 eviction 触发条件有哪些？
WiredTiger 的 eviction 由 server、worker 和队列管理，触发条件包括达到 target/trigger 阈值（如缓存使用率）。当缓存压力过大时，应用线程可能被迫协助驱逐。脏页驱逐前必须先进行 reconciliation。
