MongoDB 3.2 把 WiredTiger 设置为了默认的存储引擎（之前版本使用 MMAPV1 存储引擎），最近通过阅读 WiredTiger 源代码（在不了解其内部实现的情况下，读代码难度相当大，代码量太大，强烈建议官方多出些介绍文章），理清了 WiredTiger 的大致原理，并简单总结，不保证内容都是正确的，如有问题请指出，欢迎讨论交流。
按照 MongoDB 默认的配置，WiredTiger 的写操作会先写入 Cache，并持久化到 WAL（Write ahead log），每 60s 或 log 文件达到 2GB 时会做一次 Checkpoint，将当前的数据持久化，产生一个新的快照。WiredTiger 连接初始化时，首先将数据恢复至最新的快照状态，然后根据 WAL 恢复数据，以保证存储可靠性。
WiredTiger 的 Cache 采用 Btree 的方式组织，每个 Btree 节点为一个 page，root page 是 btree 的根节点，internal page 是 btree 的中间索引节点，leaf page 是真正存储数据的叶子节点；btree 的数据以 page 为单位按需从磁盘加载或写入磁盘。
WiredTiger 采用 Copy on write 的方式管理修改操作（insert、update、delete），修改操作会先缓存在 cache 里，持久化时，修改操作不会在原来的 leaf page 上进行，而是写入新分配的 page，每次 checkpoint 都会产生一个新的 root page。
Checkpoint 时，WiredTiger 需要将 btree 修改过的 PAGE 都进行持久化存储，每个 btree 对应磁盘上一个物理文件，btree 的每个 PAGE 以文件里的 extent 形式（由文件 offset + size 标识）存储，一个 Checkpoit 包含如下元数据：
§ root page地址，地址由文件offset，size及内容的checksum组成
§ alloc extent list地址，存储从上次checkpoint起新分配的extent列表
§ discard extent list地址，存储从上次checkpoint起丢弃的extent列表
§ available extent list地址，存储可分配的 extent 列表，只有最新的 checkpoint 包含该列表
§ file size 如需恢复到该 checkpoint 的状态，将文件 truncate 到 file size 即可
MongoDB 里一个典型的 WiredTiger 数据库存储布局大致如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$tree ├── journal │ ├── WiredTigerLog.0000000003 │ └── WiredTigerPreplog.0000000001 ├── WiredTiger ├── WiredTiger.basecfg ├── WiredTiger.lock ├── WiredTiger.turtle ├── admin │ ├── table1.wt │ └── table2.wt ├── local │ ├── table1.wt │ └── table2.wt └── WiredTiger.wt |
储基本配置信息
§ WiredTiger.lock 用于防止多个进程连接同一个 WiredTiger 数据库
§ table*.wt 存储各个 tale（数据库中的表）的数据
§ WiredTiger.wt 是特殊的 table，用于存储所有其他 table 的元数据信息
§ WiredTiger.turtle 存储 WiredTiger.wt 的元数据信息
§ journal 存储 Write ahead log
一次 Checkpoint 的大致流程如下：
对所有的 table 进行一次 Checkpoint，每个 table 的 Checkpoint 的元数据更新至 WiredTiger.wt。
对 WiredTiger.wt 进行 Checkpoint，将该 table Checkpoint 的元数据更新至临时文件 WiredTiger.turtle.set。
将 WiredTiger.turtle.set 重命名为 WiredTiger.turtle。
上述过程如中间失败，WiredTiger 在下次连接初始化时，首先将数据恢复至最新的快照状态，然后根据WAL恢复数据，以保证存储可靠性。
WiredTiger 支持行级别锁，mmapV1 支持表级别锁，在并发比较大的情况下 3.2 要比 3.0 表现的优秀点。
