摘要：為了能加快相關任務的高效執行，TaurusDB採用多執行緒技術處理的方式，增加處理器單元的吞吐能力，從而提高儲存端的執行效率。
1. TaurusDB背景
隨著雲端計算進入2.0時代，資料急劇膨脹，這對實現資料庫的高可靠、高效能、高吞吐的目標產生了巨大的挑戰。如圖1 所示，TaurusDB是華為自研的最新一代企業級具備橫向擴充套件、海量儲存能力的分散式資料庫，其採用了計算儲存分離，一寫多讀的分散式架構。將原本計算層的高密度儲存相關壓力下沉到儲存層，極大地釋放了計算層的算力。但同時將原來的儲存IO轉移到了網路IO，這也就是意味著，儲存層將面臨來自計算層風暴級的壓力。如果儲存層不能快速響應計算層的讀寫請求，會極大影響使用者的使用體驗。
圖1 TaurusDB整體架構
圖2 slice功能元件
從圖2可知，TaurusDB的儲存層，不單單隻做儲存相關的工作，也需要大量的算力，比如consolidation生成特定資料頁、compation回收舊版本資料、BufferPool快取熱點資料頁等任務。為了能加快這些任務的高效執行，我們首先能想到的就是能夠並行執行這些任務，也就是採用多執行緒技術處理的方式，增加處理器單元的吞吐能力，從而提高儲存端的執行效率。
2.執行緒池化設計思想
2.1執行緒為什麼需要池化
首先，執行緒是稀缺的資源，如果頻繁建立和銷燬執行緒的開銷是可觀的，所佔用的時間可能多於實際任務的執行；且當需要執行任務時，都去建立一個對應的執行緒去處理，那麼伺服器的資源(比如地址空間和核心引數)很快就會被耗盡，導致而導致OOM問題。
其次，通過事先建立好一定數量的執行緒並置於公共池之中，這樣當有任務需要執行時，只需從公共池取一個執行緒執行當前的任務即可，待任務結束後，此執行緒又可以執行其他任務或處於休眠狀態，等待下一次被排程，達到執行緒資源重複使用的目的。
2.2執行緒池如何管理
為了能有效的管理多執行緒，TaurusDB儲存端採用瞭如圖3的執行緒池模型。
圖3 執行緒池模型
ThreadPool: 主要負責控制執行緒池的大小、狀態變更、執行緒的建立、銷燬、排程策略的選取；
Scheduler：負責具體任務的接收、被排程的順序，並觸發任務的執行；
Worker：負責具體任務的執行；
Monitor:負責監控執行緒執行任務時是否出現異常，以及異常告警，比如執行緒執行一次任務長時間執行未能結束。
2.3 執行緒池的排程策略
當前TaurusDB儲存端執行緒池支援三種策略：先進先出排程(FifoScheduler)、定時排程(TimeScheduler)、基於容量排程(CapacityScheduler)。
對於FifoScheduler和TimeScheduler，比較容易理解。當有任務需要執行時，只需將此任務存放在一個佇列即可，有scheduler按照順序逐一排程即可。
對於CapacityScheduler，是一種基於事先為某一型別的任務預留可執行執行緒的思想，其預留的執行緒個數由下發任務的使用者指定。具體排程過程見圖4。
圖4 CapacityScheduler排程
比如：
初始化執行緒大小為10，TaskType1預留執行緒數4，TaskType2：預留執行緒數5，TaskTypeN：預留執行緒數4
當執行緒池處於如圖4狀態時，任務型別是1和3的尚未達到預留值，任務型別N已達到閾值。此時如果Threadpool中處於idle的執行緒數為1，則該執行緒將會被排程到任務型別為2的佇列中。
2.4 任務異常監控告警
我們知道，一旦任務被排程的執行緒執行過程中，可能會出現異常情況，比如執行緒死鎖，導致該任務不能按照預期推進，輕者引發系統出現CPU、IO等系統資源使用率飈高的情況，嚴重者會導致系統down情形。比如TaurusDB的儲存端，執行log的checkpoint的執行緒出現長時間卡頓，會導致儲存端舊的log不能正常回收，導致磁碟空間逐步膨脹，進而影響儲存端其他各個模組平滑的推進。如果能夠識別出處於異常狀態的執行緒，並能夠進行告警，基於事先自定義規則進行修復，將能夠持續保證儲存端業務的連續性。
執行緒池Monitor元件就是用於識別處於異常狀態的執行緒，其基本思想就是，定期巡檢執行緒池中的各執行緒處於狀態，如果發現執行緒狀態長時間未更新，則判定該執行緒處於異常狀態，上報告警，並基於相應的處理規則處理。
3. 下一步演進方向
從2.3中可以看出，CapacityScheduler策略是基於實際在執行的執行緒數，作為idle執行緒執行緒被排程的依據，尚未衡量實時任務的重要程度。考慮這樣一種場景，如果有兩種型別的任務A、B，在某一時間，用於執行A、B任務的執行緒數恰好執行緒或差值極小，但B型別任務的優先順序大於A任務，這時可能出現idle執行緒被排程執行A型別任務，B型別任務不能分配到充足的執行緒數(預留值是靜態分配)，用於加快推進任務的處理。
考慮的方案：
1.限制型別任務型別佇列的長度，這樣可以均衡各型別任務的排程，不至於某一類或幾類任務數過多；
2.在系統資源有限的前提下，支援動態伸縮執行緒池大小的功能，這樣可以在工作負載過重時，擴充執行緒池大小，用於排程到急需執行的任務；
3.099進一步細化CapacityScheduler策略，採用任務的重要程度和實際執行的執行緒數的規則，作為idle執行緒被排程的依據。