雲端海量任務調度系統資料庫設計

背景

任務調度系統中的任務狀態管理，通常會用到資料庫來存儲任務調度的過程狀態，控制任務的鎖等。

《advisory lock 實現高並發非堵塞式 業務鎖》

如果是小量任務，是挺好實現的，但是每小時處理幾十億或者幾億的任務，如何設計這樣的任務狀態管理資料庫呢？

挑戰

對於一個面向多個用戶的任務調度平台（例如雲端的任務調度平台，將面向所有租戶使用）。

較大的挑戰是任務數據的寫入（海量），另一個是任務狀態的更新（海量，每個任務至少被更新一次）。

雲端海量任務調度資料庫設計

雲端任務調度存在一些特性：

1、用戶和用戶之間的任務是沒有關係的，單個用戶的任務在調度時可能有依賴關係。

2、數據量龐大。

3、任務通常都有最終穩定狀態，穩定後，對應的任務記錄就不會變化了。

針對以上幾個特點，採樣PostgreSQL設計：

1、任務數據生成後寫入任務處理表

2、任務處理表使用rotate設計（例如每小時一個rotate表），處理完的數據直接清除，不需要VACUUM。

3、分區方面，任務處理表採樣用戶級分區，在獲取需要處理的任務時更加的精鍊（減少冗餘掃描）。

4、當任務達到最終狀態時，從任務運行表刪除，寫入歷史表。

5、早期的歷史表，從RDS PG中刪除，寫入阿里雲OSS，使用RDS PG OSS外部表介面可以訪問到這些歷史數據。

DEMO設計

1、初始任務表，用於存儲用戶生成的任務。

create table task_init ( -- 任務初始表

2、任務歷史表，用於存儲任務的最終狀態。

create table task_hist ( -- 任務歷史表

3、為了簡化測試，按用戶ID進行分區。（前面提到的rotate設計，多級分區設計，請參考本文末尾的文章）

do language plpgsql $$

4、為了測試方便，使用schemaless的設計，將用戶任務的初始數據生成寫入放在PLPGSQL邏輯中。

create or replace function ins_task_init(

5、運行任務，分為幾個步驟。

5.1、從任務表讀取任務。

5.2、用戶執行任務。

5.3、反饋執行的結果，不成功的任務更新task_init表，對於執行成功（並結束）的任務，數據從task_init遷移到task_hist。

為了測試資料庫的性能，我講這三步的邏輯寫到plpgsql裡面。同時使用delete limit的特性，一次批量取出若干條任務。

這裡使用CTID行號定位，達到最佳的性能。不僅免去了索引的使用，而且性能更佳。

這裡使用了advisory lock，使得單個用戶不會出現並行任務。（實際業務中，可以並行。）

這裡沒有測試更新狀態，task_init還有少量更新(相比insert和delete，比例很少，可以忽略)，比如任務失敗的情況。

關閉task_init表的autovacuum，採用rotate的形式進行處理。

create or replace function run_task(

6、測試分解動作。

寫入初始任務

性能壓測

1、生成任務的性能

vi ins.sql

2、運行任務的性能(一次批量取10000條任務)

vi run.sql

單獨的測試數據

1、生成任務，23.9萬條/s

2、消耗任務，27.2萬條/s

生成與消耗任務同時運行的測試數據

1、生成任務，16.8萬條/s

2、消耗任務，大於16.8萬條/s

沒有任何任務堆積。

小結

PostgreSQL在雲端海量任務調度系統中，發揮了重要的作用。

單個PostgreSQL實例，已經可以處理每個小時 的任務生成，以及 的任務消耗。

任務調度系統比MQ更加複雜，類似MQ的超集，所以用戶如果有MQ的需求，實際上使用RDS PostgreSQL也是可以的。性能指標比上面的測試更好。

參考

《advisory lock 實現高並發非堵塞式 業務鎖》

《PostgreSQL schemaless 的實現(類mongodb collection)》

《行為、審計日誌 (實時索引/實時搜索)建模 - 最佳實踐 2》

《在PostgreSQL中實現update | delete limit》

《塊級(ctid)掃描在IoT(物聯網)極限寫和消費讀並存場景的應用》

《PostgreSQL 10.0 preview 功能增強 - 內置分區表》

《PostgreSQL 9.5+ 高效分區表實現 - pg_pathman》

《PostgreSQL 數據rotate用法介紹 - 按時間覆蓋歷史數據》

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！