![](https://www-cdn.nebula-graph.com.cn/nebula-blog/TM01.png)

講解 Task Manager 之前，在這裡先介紹一些 Task Manager 會使用到的概念術語。

圖資料庫 Nebula Graph 中，存在一些長期在後臺執行的任務，我們稱之為 Job。儲存層存在的 DBA 使用的部分指令，比如：資料完成匯入後，想在全域性做一次 compaction，都是 Job 範疇。

作為一個分散式的系統，Nebula Graph 中 Job 由不同的 storaged 完成，而我們管一個 storaged 上執行的 Job 子任務叫做 Task。Job 的控制由 metad 上的 Job Manager 負責，而 Task 的控制由 storaged 上的 Task Manager 負責。

在本文中，我們著重講述如何對長耗時的 Task 進行管理與排程進一步提升資料庫效能。

## Task Manager 要解決的問題

上文說到 storaged 上的 Task Manager 控制的 Task 是 meta 控制的 Job 的子任務，那 Task Manager 它自己具體解決什麼問題呢？在 Nebula Graph 中 Task Manager 主要解決了以下 2 個問題：

- 將之前透過 HTTP 的傳送方式改為 RPC（Thrift）
一般使用者在搭建叢集時，知道 storaged 之間通訊使用 Thrift 協議，會為 Thrift 所需埠開放防火牆，但是可能意識不到 Nebula Graph 還需要使用 HTTP 埠，我們遇到過多次社群使用者實踐忘記開放 HTTP 埠的事情。
- storaged 對於 Task 有排程能力
這塊內容將在本文下面章節展開講述。

## Task Manager 在 Nebula Graph 中的位置

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/TM02.png)

## Task Manager 體系中的 meta

在 Task Manager 體系中,  metad（JobManager）的任務是根據 graphd 中傳過來的一個 Job Request，選出對應的 storaged host，並拼組出 Task Request 發給對應的 storaged。不難發現，體系中 meta 接受 Job Request，拼組 Task Request , 傳送 Task Request 及接受 Task 返回結果，這些邏輯的套路是穩定的。而如何拼組 TaskRequest，將 Task Request 發給哪些 storaged 則會根據不同的 Job 有所變化。JobManager 用 `模板策略`  + `簡單工廠` 以應對未來的擴充套件。

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/TM03.png)

讓未來的 Job 同樣繼承於 MetaJobExecutor，並實現 prepare() 和 execute() 方法即可。

## Task Manager 的排程控制

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/TM04.png)

之前提到的，Task Manager 的排程控制希望做到 2 點：

- 系統資源足夠時，儘可能的高併發執行 Task
- 系統資源吃緊時，讓所有執行中的 Task 佔用的資源不要超過某一個設定的閾值。

### 高併發執行 Task

Task Manager 將系統資源中自己持有的執行緒稱之為 Worker。Task Manager 有一個現實中的模擬原型——銀行的營業廳。想象一下, 我們去銀行辦業務時會有以下幾步:

- 場景 1：在門口的排號機拿一個號
- 場景 2：在大廳找個位置, 邊玩手機邊等叫號
- 場景 3：等叫到號時, 到指定視窗辦理

同時, 你還會碰到這樣那樣的問題:

- 場景4：VIP 可以插隊
- 場景5：你可能排著隊, 因為某些原因, 放棄了本次業務
- 場景6：你可能排著排著隊, 銀行就關門了

那麼, 整理一下, 這也就是 Task Manager 的基本需求

1. Task 按 FIFO 順序執行：不同的 Task 有不同的優先順序，高優先順序的可以插隊
2. 使用者可取消一個排隊中的 Task
2. storaged 隨時 shutdown
2. 一個 Task，為了使其儘可能高的併發，會被拆分為多個 SubTask，SubTask 是每個 Worker 真正執行的任務
2. Task Manager 是全域性唯一例項，要考慮多執行緒安全性

於是, 有了如下實現:

- 實現 1：用 Thrift 結構中的 JobId 和 TaskId，確定一個 Task，稱為 Task Handle。
- 實現 2：TaskManager 會有一個 Blocking Queue，負責讓 Task 的 Handle 排隊執行（排號機），而 Blocking Queue 本身執行緒安全。
- 實現 3：Blocking Queue 同時支援不同的優先順序, 高優先順序先出隊（VIP 插隊的功能）。
- 實現 4：Task Manager 維持一個全域性唯一的 Map，key 是 Task Handle，value 是具體的 Task（銀行的大廳）。在 Nebula Graph 中採用了 folly 的 Concurrent Hash Map，執行緒安全的 Map。
- 實現 5：如果有使用者 cancel Task，直接在根據 Handle 找到 Map 中對應的 Task，並標記 cancel，對 queue 中的 Handle 不做處理。
- 實現 6：如果有正在執行的 Task，對於 storaged 的 shutdown 會等到這個 Task 正在執行的 subTask 執行完畢才返回。

### 限定 Task 佔用的資源閾值

保證不超過閾值還是很簡單的，因為 Worker 就是執行緒，只要讓所有的 Worker 都出自一個執行緒池，就可以保證最大的 Worker 數。麻煩的是將子任務平均地分配到 Worker 中, 我們來討論下方案:

#### 方法一：使用 Round-robin 新增任務

最簡單的方法是用 Round-robin 的方式來新增任務。也就是將 Task 分解為 Sub Task 之後, 依次追加到現在的各個 Worker 中。

但是可能會有問題, 比如說, 我有 3 個 Worker, 2 個 Task（藍色為 Task 1，黃色為 Task 2）：

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/TM05.png)

Round-robin 圖 1

假如 Task 2 中的 Sub Task 執行遠快於 Task1 的, 那麼好的並行策略應該是這樣：

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/TM06.png)

Round-robin 圖 2

簡單粗暴的 Round-robin 會讓 Task 2 的完成時間依賴於 Task 1（見 Round-robin 圖1）。

#### 方法二：一組 worker 處理一個 Task

針對方法一可能會出現的情況，設定專門的 Worker 只處理指定的 Task，從而避免多個 Task 相互依賴問題。但是依然不夠好, 比如說：

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/TM07.png)

很難保證每個 Sub Task 執行時間基本相同，假設 Sub Task 1 的執行明顯慢於其他的 Sub Task，那麼好的執行策略應該是這樣的：

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/TM08.png)

這個方案還是避免不了 1 核有難，10 核圍觀的問題 ?。

#### 方法三：Nebula Graph 採用的解決方案

在 Nebula Graph 中 Task Manager 會將 Task 的 Handle 交給 N 個 Worker。N 由總 Worker 數、總 Sub Task 數，以及 DBA 在提交 Job 時指定的併發引數共同決定。

每個 Task 內部維護一個 Blocking Queue（下圖的 Sub Task Queue），存放 Sub Task。Worker 在執行時，根據自己持有的 Handle 先找到 Task，再從 Task 的 Block Queue 中獲取 Sub Task。

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/TM09.png)

## 設計補充說明

問題 1: 為什麼不直接將 Task 放到 Blocking Queue 排隊，而是拆成兩部分，將 Task 儲存在 Map 裡，讓 Task Handle 排隊?

> 主要原因是 C++ 多執行緒基礎設施不好支援這種邏輯。Task 需要支援 cancel。假設 Task 放在 Blocking Queue 中，就需要 Blocking Queue 支援定位到其中的某一個 Task 的能力。而當前 folly 中的 Blocking Queue 都沒有此類介面。

問題 2: 什麼樣的 Job 有 VIP 待遇?

> 當前 Task Manager 支援的 compaction / rebuild index 對執行時間並不敏感，支援類似 count(*) 查詢操作功能尚在開發中。考慮到使用者希望在一個相對短的時間內完成 count(*) ，那麼假如正好碰上了 storaged 在做多個 compaction，還是希望 count(*) 可以優先執行，而非在所有 compaction 之後再開始做。

本文中如有任何錯誤或疏漏歡迎去 GitHub：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula) issue 區向我們提 issue 或者前往官方論壇：[https://discuss.nebula-graph.com.cn/](https://discuss.nebula-graph.com.cn/) 的 `建議反饋` 分類下提建議 ?；加入 Nebula Graph 交流群，請聯絡 Nebula Graph 官方小助手微訊號：[NebulaGraphbot](https://www-cdn.nebula-graph.com.cn/nebula-blog/nbot.png)

> 作者有話說：Hi，我是 我是 lionel.liu，是圖資料 Nebula Graph 研發工程師，對資料庫查詢引擎有濃厚的興趣，希望本次的經驗分享能給大家帶來幫助，如有不當之處也希望能幫忙糾正，謝謝~

Task Manager 的設計簡述

相關文章