1. MongoDB 多引擎体系 — WiredTiger
MongoDB v.3.0之前的版本，默认使用MMAP(MMap引擎)方式对内存中的数据进行写盘存储，遭受了很多诟病。比如并发受限的表锁、不支持压缩、不可控的IO操作等，MMAP甚至不能称作一个完整的存储引擎(笔者的个人观点)，对数据(Btree的数据页、索引页)的操作甚至要依赖os的mmap(in_page_cache)刷盘，并且os的page 4k为IO单元对数据库本身就是不友好的，再加上其实数据库自身应该比OS更懂数据的layout，比如哪些是热数据，哪些是索引(较数据页更需要留在内存里)来组织LRU。
MongoDB v3.0版本一个重大的更新是加入了WiredTiger，也使得Mongo代码架构里支持了StorageEngine的抽象层(接口层更多细节，参见@林青 大神的文章http://www.atatech.org/articles/56080)，为后面RocksDB、Memory等做了铺垫。WiredTiger引擎(后面简称wt引擎)面向多核、Page IO优化做了很多工作(比如加入HazardPointer、分离锁，为了增大并发内存Page结构和磁盘Page结构解耦以及支持变长Page-面向大吞吐设备的IO适配)。很多测试报告显示使用了wt之后Mongo的性能有很大提升。本文通过项目里对wt的子模块进行了解，主要关注cache相关设计，更多wt引擎相关请见后续文章。
2. WiredTiger整体架构
wt引擎是基于btree索引实现的，和InnoDB引擎有很多设计和名词上相似的地方，大家可以类比。wt对外的api接口是以table(类比Mysql的表和MongoDB的collection) + kv存储形式提供的，key是int64_t类型(类似MongoDB的_id)，value是byte[]类型(这里通过byteArray来实现MongoDB上层schema free的bson结构)。上层通过cursor方式来实现数据的search/insert/update/remove操作。内部通过journal_log、checkpoint、cache(btree/cache_evict)、block_manager子模块协调访问IO存储(这里主要列出本文相关模块，sweep、transaction、bloom/lsm等未列出)
- session 模块，负责和wt引擎上层交互的句柄，每个session会关联多个cursor，cursor属于一个session
- cache 模块，主要有内存中的btree page(数据页，索引页，溢出页)构成
- evict 模块，如果cache内存紧张，触发cache淘汰，便利btree，并根据lru排序淘汰
- Journal 模块，WAL log，类似InnoDB的redolog，保证数据持久化，通过定时和定量阈值来flush
- checkpoint 模块，类似InnoDB checkpoint机制，异步执行btree刷盘，checkpoint之后通知log模块更新log_ckpt_lsn(lsn概念和InnoDB一致)
- block manager模块，负责磁盘IO的读写，cache、evict、checkpoint模块均通过该模块访问磁盘
3. cache pool
wt有个shard cache(cache pool)的概念，MongoDB并未使用。因为cache本身的功能和InnoDB buffer pool类似，这里暂且把wiredTiger的cache称作cache pool也算合理。cache pool主要存放内存中btree page为单位的页，页类型及cache pool相关运行参数可见 http://gitlab.alibaba-inc.com/dds/dds-documents/blob/develop/社区教程文档/wiredTiger_cache_运行参数.md,cache的读入和淘汰写入都是以page为单位(基本上所有存储引擎都是如此)。基本结构如图:
(图片来自WiredTiger Github官方wiki)
- 基本page类型：root_page(btree根节点), internal_page(索引页), leaf_page(数据页, 叶子节点)
- 结构：每个page被包含在一个REF里面(可以看做是page的容器), root_page/internal_page 包含一个refArray数组，包含下层节点的指针，home(红色线)指向父节点
wt的btree相较于InnoDB有些不一样的地方(详细结构见https://github.com/wiredtiger/wiredtiger/wiki/Reconciliation-overview)，InnoDB的内存中的page结构和磁盘上的page结构是一样的，都是紧凑的binary，修改产生的脏页会in place的更新到原有磁盘的page上, 这样的好处是刷盘时，直接把16k的page，按字节数组的方式一次性刷下去即可。
WiredTiger将磁盘上的page读上来之后，会在内存中构建成另外一种复杂结构，这个结构较binary结构好处就是可以重新组织或嵌入具有更高并发性的结构，比如wt使用的HazardPointer，对page刷盘时，其实就是对该页的HazardPointer的'写获取'操作，并且在刷盘时保持 原有磁盘上的page不变，直接找一个新的page空间，把内存里page的修改(保存在page的modify_list中)变成磁盘page的结构写入 ，这个page刷盘的过程称为reconcile(wt里很多生僻的名词)。这样的好处是对不修改原有page，就能更好的并发，并且不像InnoDB一样，需要一个DoubleWriteBuffer保证非disk block 512B写时对原有页可能发生conrrupt。(这里有个小问题，如果是更新都写入新page，如果每次都只是更新page中很小的数据，数据的空间占用会比较大，待验证？!)
WiredTiger也提供了类似InnoDB的checkpoint机制：每个客户端的写请求会先通过journal进行持久化，这里类似redolog都是顺序IO，并且提供了类似innodb_flush_log_at_trx_commit的{j: true}参数。那么，在wt里面产生的cache脏页，就用在后台'慢慢'的刷。当写入到一定程度或者时间后，或作一次checkpoint把cache中的数据刷入磁盘，并且做fsync, 然后通知journal更新checkpoint offset，即可丢弃之前的journal。这里在每次checkpoint后，都会产生一个新的root page(也就是一个新的btree，一个bree对应一个物理文件)，同时会在journal写入这个checkpoint事件。
3.1 cache pool 刷盘
写请求写入journal后就可以保证Durability，后续wt引擎遇到如下情况时，会触发cache的刷盘动作：
- checkpoint
checkpoint时会遍历所有btree，把btree的所有leaf_page做reconcile操作，然后对重新分配root_page，触发的阈值包括：
- journal容量达到阈值，默认2G
- 每隔60s执行一次
- cache evict
evict线程会根据现在cache的使用量，分段扫描一些page(可能是drity page或clean page)，进行淘汰，释放cache空间，主要受如下4个参数影响：
eviction_trigger：cache总使用量达到该百分比时，触发evict操作
eviction_target：触发上述参数evict后，需要将cache总使用量降低到该百分比水位，才停止evict
eviction_dirty_trigger：cache脏页使用量到该百分比时，触发evict操作
eviction_dirty_target：触发上述参数evict后，需要将cache脏页使用量降低到该百分比水位，才停止evict
(WiredTiger v2.8.1 一般情况使用情况eviction_trigger > eviction_target > eviction_dirty_trigger > eviction_dirty_target，WiredTiger v2.9之后版本对着四个参数的意义进行了调整！)
- application evict
如果写入量一直很大，那么用户请求处理线程就会阻塞并参与evict的执行，这也是一种保护措施，当IO量很大时，做到同步阻塞上面的请求
4 cache evict
4.1 evict线程模型
cache evict在wt v2.8.1早期版本时，采用的是server-worker模型，1个server线程负责扫描btree找到一些page，然后进行lru排序，放入一个evict_queue中，再由worker线程消费，进行page evict动作。后面v2.8.1在MongoDB v3.2.9这个版本中，对线程模型进行了升级， 将server线程和worker线程合并(worker通过抢一把evict_pass_lock锁来成为server)，相当于N个worker线程，同一时刻，有一个worker会成为server，负责执行evict_pass(扫描btree，并填充evict_queue)的工作，较少了切换的代价 。并且把原来单一的evict_queue变成了两个，降低了server、worker之间操作一个queue的概率减少冲突，增加了并发。
虽然线程模型做了调整，但从功能上还是server-worker的模式，见下图:
4.2 Btree扫描策略
每次evict_server执行cache pass是对所有btree的一次扫描，会根据当前cache情况最多扫描100个page出来。btree的扫描是迭代的，结束时会记录当前扫描道德btree的位置，下次继续从这个地方开始walk，每个btree最多扫描出10个page，如果这个btree被exclusive独占，如checkpoint正在访问这个btree，则跳过 ，这是为了让btree所有page都有可能被扫描到。如果扫描了足够多的page，则会停止本次cache pass，进入page的evict阶段。
这个扫描策略应该可以page尽可能全的被覆盖，但其实不具备LRU的特性(evict_queue里的page排序是基于LRU，也就是说扫描出来的page是会使用LRU)。如果看一下HBase或者InnoDB的分级扫描策略，就会感觉wt引擎的这种阶段性扫描在某些场景下还是不够友好的。比如 InnoDB的分级cache，会把buffer pool中的page list分成两部分，new_list和old_list，分别占5/8和3/8左右，新访问使用的page会在old_list里，如果这个page被再次访问到，则移动到new_list，如不访问则可能在old_list里被淘汰掉 。这就防止了select * from table类似这种fullScan时对buffer pool的污染 (详情可参考 http://dev.mysql.com/doc/refman/5.6/en/innodb-buffer-pool.html )，这里wt引擎其实做的还有欠缺。
4.3 LRU策略
扫描完成后的evict_queue，需要对每个里面page做评分排序，每个page的评分由page->read_gen(可理解成page的存活周期，如果经历过cache淘汰越多，但没被淘汰，就越高), 以及page类型共同决定，见代码：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
2 * 获得page的评分，分数越低越容易被淘汰掉
3 */
4static inline uint64_t
5__evict_read_gen(const WT_EVICT_ENTRY *entry)
6{
7 WT_BTREE *btree;
8 WT_PAGE *page;
9 uint64_t read_gen;
10
11 btree = entry->btree;
12
13 page = entry->ref->page;
14
15 // 周期最老的页，需要马上evict，给最低分WT_READGEN_OLDEST == 1
16 if (page->read_gen == WT_READGEN_OLDEST)
17 return (WT_READGEN_OLDEST);
18
19 // 如果dhandle(btree文件)已经要被回收，同样给最低分
20 if (!WT_PAGE_IS_INTERNAL(page) &&
21 F_ISSET(btree->dhandle, WT_DHANDLE_DEAD))
22 return (WT_READGEN_OLDEST);
23
24 // 如果page为空，也给最低分
25 if (__wt_page_is_empty(page))
26 return (WT_READGEN_OLDEST);
27
28 // 如果是internal page索引页, 则加上一个倾斜分数1000000分，
29 // 这里是希望索引页尽量不淘汰
30 read_gen = page->read_gen + btree->evict_priority;
31 if (WT_PAGE_IS_INTERNAL(page))
32 read_gen += WT_EVICT_INT_SKEW;
33
34 return (read_gen);
35}
36
按评分排序后，得到一个分数从小到大的有序队列，这个时候需要计算candidate(evict_page是即将被淘汰的页，candidate page是本次决定淘汰的页，evict > candicate)，继续上代码：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
2 WT_EVICT_PASS_AGGRESSIVE | WT_EVICT_PASS_WOULD_BLOCK)) {
3 // 此时cache空间已经非常紧张了，进入aggressive模式或者application用户
4 // 线程淘汰模式了，则把全部evict_page变成candidate_page
5 evict_queue->evict_candidates = entries;
6 } else {
7 // 寻找第一个不是WT_READGEN_OLDEST的分数
8 read_gen_oldest = WT_READGEN_OLDEST;
9 for (candidates = 0; candidates < entries; ++candidates) {
10 read_gen_oldest =
11 __evict_read_gen(
12 &evict_queue->evict_queue[candidates]);
13 if (read_gen_oldest != WT_READGEN_OLDEST)
14 break;
15 }
16
17 // 此处意味着全部page的分数都是WT_READGEN_OLDEST，则全部变成
18 // candidate
19 if (read_gen_oldest == WT_READGEN_OLDEST)
20 evict_queue->evict_candidates = entries;
21 else if (candidates >= entries / 2)
22 // 如果第一个不是WT_READGEN_OLDEST的分数位置是在
23 // 中间位置或中间偏后面的位置，则直接取到这个点
24 evict_queue->evict_candidates = candidates;
25 else {
26 cache->read_gen_oldest = read_gen_oldest;
27
28 // 去一个适中的值，差不多在这个点的值和最后点的值得3/4处
29 // 也就是说在当前这个点到末尾之间去一个值作为平衡点
30 cutoff =
31 (3 * read_gen_oldest + __evict_read_gen(
32 &evict_queue->evict_queue[entries - 1])) / 4;
33
34 // 在至少10%和至多50%间找一个小于cutoff的边界作为
35 // candidate数量
36 for (candidates = 1 + entries / 10;
37 candidates < entries / 2;
38 candidates++)
39 if (__evict_read_gen(
40 &evict_queue->evict_queue[candidates]) >
41 cutoff)
42 break;
43 evict_queue->evict_candidates = candidates;
44 }
45 }
46
4.3 Cache 现存问题及CacheHang问题
上述分析了Cache相关的设计，其实可以看出evict还是有些精巧的地方，单还不够完善，尤其是在cache evict和checkpoint同时发生，或者evict_server不能找到可以evict的page时的退让策略，触发了一些线上问题，本文的下半节《MongoDB WiredTiger 存储引擎cache_pool设计 (下) — 实践篇》将对次进行深入讨论
