这次还是以介绍TokuDB内部机制为主, 本篇来谈谈TokuDB内部的线程池模型。 TokuDB内部有一个线程池实现kibbutz, 代码: [https://github.com/Tokutek/ft-index/blob/master/util/kibbutz.cc](https://github.com/Tokutek/ft-index/blob/master/util/kibbutz.cc) 其调度思想基于[work-stealing](http://en.wikipedia.org/wiki/Work_stealing), 代码也很简洁, 大体思路就是:维护一个任务队列, 空闲线程自己去这个队列领取任务。 kibbutz中文为“基布兹”,是以色列的一个集体社区,感兴趣的[戳这里](http://zh.wikipedia.org/wiki/%E5%9F%BA%E5%B8%83%E5%85%B9)。 TokuDB内部线程池按功能可以分为以下3大块: **节点“饱和”apply线程池** 当一个节点“饱和”的时候,TokuDB需要把节点message buffer中的数据apply到子节点(这个行为是由TokuDB的特殊索引结构决定)。 这个线程池的作用是实现并发apply“饱和”节点,线程数目为物理CPU的个数。 **缓存专用线程池** 这个线程池专门为缓存服务,包括两大块: a) 节点预读线程,比如做区间查找的时候,在某些条件下会触发子节点预读,提前在后台线程把节点读取到缓存。 b) LRU剔除线程,当缓存大小到达高水位的时候,后台线程把LRU尾端的脏节点刷到磁盘,并从LRU中清除。 这个池子里的线程数目较多,干的活也比较重,线程数目为物理CPU数*2。 **checkpoint克隆线程池** 这个线程池比较特殊。 做checkpoint的时候,如果一个节点处于“pin”状态,并且它是可克隆的,就使用后台线程把它的数据克隆出来并刷到磁盘,这样checkpoint可以继续进行下去(如果此节点不可克隆,checkpoint线程会一直等到这个pin状态结束)。 这个线程数为物理CPU数/4(如果CPU > 4)。 好的线程池设计+好的任务调度算法,应该是一个引擎高效的最基本条件,让任务尽量并行起来。