摘要：為了能加快相關任務的高效執行，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線程被排程的依據。
點選關注，第一時間了解華為雲新鮮技術~