CUBRID 中的執行緒模型

cubrid 中的執行緒模型

2023年11月15日

本文旨在說明 cubrid 這一資料庫引擎中的執行緒模型。將分別從客戶端和伺服器端兩個視角描述乙個請求是被 cubrid 響應的過程。

下圖描述了整體的執行緒結構：

在描述請求處理過程之前有必要先說一下各個執行緒所扮演的角色（以下說明都是基於linux平台，windows下的表現會略有不同，文後將作以說明）。如圖所示，cubrid 伺服器端共有2個程序： 1. cub_master 對客戶端來講只有master是可見的。為了與cub_server 通訊，客戶端首先與cub_mater建立連線。cub_master將客戶端socket傳遞給cub_server 並由其儲存在css_conn_array佇列中。

2. cub_server

cub_server以多執行緒的形式進行分工。

a) master thread

處理來自master程序的請求。主要負責以下三件事情：

（1）檢測cub_master程序的狀態

（2）處理新連線請求

（3）處理shutdown請求

b) worker thread

客戶端請求的真正執行者。

c) daemon thread

cubrid 中共有6個守護執行緒，分別負責以下工作：

（1） dead lock detection

（2） checkpoint

（3） oob-handler

（4） page flush

（5） flush control

（6） log flush 下面以請求如何被處理的流程來說明各個程序執行緒之間是如何協同工作的。

1. 當乙個新的客戶端試圖與server建立連線時，它需要首先與cub_master建立連線。

2. cub_master將與客戶端進行通訊的套接字傳遞給cub_server中的master thread。

3. master_thread在接到新連線請求之後，首先從css_conn_array空取出乙個空閒的conn_entry將此套接字放入其中，生成乙個完整的conn_entry（除套接字以外，還包括client_id, transaction_id, request_id等資訊），並將其設定為active狀態。

4. master_thread利用步驟3中生成的conn_entry 生成乙個新的job_entry 放入 css_job_queue當中，並設定其handle_function 為connection_handler。完成之後喚醒乙個正在等待的worker_thread

5. worker_thread被喚醒後取回job_entry, 開始執行connection_handler函式。此函式的功能就是利用conn_entry中套接字與客戶端進行通訊，接收它的request，生成新的job_entry，放入css_job_queue，喚醒另外乙個worker_thread。此時job_entry的handle_function 為request_handler

6. 步驟5中被喚醒的worker_thread開始執行request_handler。至此，客戶端的request得到響應。執行完成後，直接將結果reply給客戶端。乙個requesst完成。

7. 此客戶端再次傳送request時跳過步驟1~4，重複步驟5、6，直到客戶端退出。說明：

在windows平台下，無法在程序間傳遞描述符，所以步驟2將改變為cub_master將master_thread的port號返回給client，client重新建立乙個到此port口的連線。

CUBRID 中的執行緒模型

CUBRID 中的執行緒模型

CUBRID 中的執行緒模型

OpenStack Nova中的執行緒模型

相關推薦