wiredTiger存储引擎evict流程

        最近对3.4版本的wiredTiger源码进行了学习。为方便日后回顾，对学习过程中的个人理解，做了一些初步总结。本篇文章主要为本人对wiredTiger内部一个相对比较重要的流程eviction的理解，很多代码细节就不具体记录了，只是记录大概的流程以及原理。    

1. WiredTiger存储引擎数据生命周期

    如图所示，图中大概标示了wiredTiger数据的循环周期，wiredTiger在内存中是以btree的格式组织数据的

2.Evict流程

     Evict整个的实质主要是将内存中的page淘汰出内存，这个流程中存在两个淘汰队列分别为待淘汰的填充队列和当前淘汰队列，evict会不断地将符合淘汰条件的page交替加入 待淘汰queue，然后会从淘汰队列中将page淘汰出内存。待淘汰queue和当前淘汰queue角色会进行切换。

     Evict有两种触发方式，一种是wiredTiger内部线程去触发，分为server和worker线程，另一种为用户（application）操作（读写等）直接调用check函数触发。

     从线程工作内容来说，一类线程负责扫描内存中的btree，将符合的page加入队列，在evict很繁忙的时候也会参与淘汰页，此类线程必然属于wiredTiger内部线程，代码中称之为server线程，一个wiredTiger实例中只有一个。另一类线程负责将队列中的page淘汰出内存，此类线程中属于内部线程的那些线程即为worker线程。

     大概相关方法如下图所示：

由图可以看出核心方法由evict pass（筛选页）和evict page（淘汰页）两部分组成

2.1 Evict pass

     Evit pass的核心逻辑就是给evict queue内添加符合要求的page，以及评估当前全局evict 程度。这期间会维护两个指标evict_empty_score和evict_aggressive_score，可以通过mongo的serverStatus中查看到相关的信息。

     evict_empty_score代表LRU queue的最近出现空的频率，分数越高说明evict queue越空闲。如果为0，代表队列长时间不为空，如果为100，代表evict queue比较空。evict_aggressive_score则代表evict进程当前的“卖力”程度，Evict pass每20ms检查一次，是否有任何page evict成功，如果没有evict 成功，则aggressive score+1，如果一直没有evict成功，那么预期200ms后aggressive score预期会加到10这个阈值，扫描线程会增加更多的待evict page进入queue，继续检查，如果还是没有evict，2S后这个分数就会到100。如果此时用户线程也参与到evict，这时候wiredTiger内部就会认为cache stuck了。

     evict pass大概流程如下图所示：

 2.2 Evict page

      然后是淘汰页流程。进入淘汰页大概流程如下图所示：

   想了解更多精彩内容，请扫码关注【HW云数据库】