解密TaurusDB儲存端高併發之執行緒池

qwer1030274531發表於2020-09-15
摘要:為了能加快相關任務的高效執行,TaurusDB採用多執行緒技術處理的方式,增加處理器單元的吞吐能力,從而提高儲存端的執行效率。

1. TaurusDB背景

隨著雲端計算進入2.0時代,資料急劇膨脹,這對實現資料庫的高可靠、高效能、高吞吐的目標產生了巨大的挑戰。如圖1 所示,TaurusDB是華為自研的最新一代企業級具備橫向擴充套件、海量儲存能力的分散式資料庫,其採用了計算儲存分離,一寫多讀的分散式架構。將原本計算層的高密度儲存相關壓力下沉到儲存層,極大地釋放了計算層的算力。但同時將原來的儲存IO轉移到了網路IO,這也就是意味著,儲存層將面臨來自計算層風暴級的壓力。如果儲存層不能快速響應計算層的讀寫請求,會極大影響使用者的使用體驗。

解密TaurusDB儲存端高併發之執行緒池圖1 TaurusDB整體架構解密TaurusDB儲存端高併發之執行緒池圖2 slice功能元件

從圖2可知,TaurusDB的儲存層,不單單隻做儲存相關的工作,也需要大量的算力,比如consolidation生成特定資料頁、compation回收舊版本資料、BufferPool快取熱點資料頁等任務。為了能加快這些任務的高效執行,我們首先能想到的就是能夠並行執行這些任務,也就是採用多執行緒技術處理的方式,增加處理器單元的吞吐能力,從而提高儲存端的執行效率。

2.執行緒池化設計思想

2.1執行緒為什麼需要池化

首先,執行緒是稀缺的資源,如果頻繁建立和銷燬執行緒的開銷是可觀的,所佔用的時間可能多於實際任務的執行;且當需要執行任務時,都去建立一個對應的執行緒去處理,那麼伺服器的資源(比如地址空間和核心引數)很快就會被耗盡,導致而導致OOM問題。

其次,通過事先建立好一定數量的執行緒並置於公共池之中,這樣當有任務需要執行時,只需從公共池取一個執行緒執行當前的任務即可,待任務結束後,此執行緒又可以執行其他任務或處於休眠狀態,等待下一次被排程,達到執行緒資源重複使用的目的。

2.2執行緒池如何管理

為了能有效的管理多執行緒,TaurusDB儲存端採用瞭如圖3的執行緒池模型。

解密TaurusDB儲存端高併發之執行緒池圖3 執行緒池模型

ThreadPool: 主要負責控制執行緒池的大小、狀態變更、執行緒的建立、銷燬、排程策略的選取;

Scheduler:負責具體任務的接收、被排程的順序,並觸發任務的執行;

Worker:負責具體任務的執行;

Monitor:負責監控執行緒執行任務時是否出現異常,以及異常告警,比如執行緒執行一次任務長時間執行未能結束。

2.3 執行緒池的排程策略

當前TaurusDB儲存端執行緒池支援三種策略:先進先出排程(FifoScheduler)、定時排程(TimeScheduler)、基於容量排程(CapacityScheduler)。

對於FifoScheduler和TimeScheduler,比較容易理解。當有任務需要執行時,只需將此任務存放在一個佇列即可,有scheduler按照順序逐一排程即可。

對於CapacityScheduler,是一種基於事先為某一型別的任務預留可執行執行緒的思想,其預留的執行緒個數由下發任務的使用者指定。具體排程過程見圖4。

解密TaurusDB儲存端高併發之執行緒池圖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執行緒被排程的依據。

 

點選關注,第一時間瞭解華為雲新鮮技術~

相關文章