這次還是以介紹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)。 好的線程池設計+好的任務調度算法，應該是一個引擎高效的最基本條件，讓任務盡量并行起來。