標題: 「面試人生 - 設計一個簡易的分散式 Job Scheduler」 類別: others 連結: https://medium.com/@raxshah/system-design-design-a-distributed-job-scheduler-kiss-interview-series-753107c0104c
本篇文章是一個面試技術文，探討開發一個類似 Job Scheduler 的專案時應該要如何去設計整體系統來完成需求，整體的架構基於 KISS 的原則，就是簡單為主。
整個流程原則基本上是
- 理解所有功能需求，包含功能面以及非功能面
- 瞭解可能的資料，根據規模大小與功能需求去推估出整體的規模大小
- 根據上述需求去規劃整體架構，其中規模大小有時候可以幫忙歸納出 ”讀寫“彼此的比例，這個會影響架構設計
功能面常見類型如
- 針對使用者提供何種操作，譬如遞交一個 Job, 列出所有 Job(當前，歷史)
- 每個 Job 的運行時間限制(ex, 5min)，同時 Job 可以重複運行或是只運行一次等不同用法
- Job 本身也有優先度的設計，可以插隊等
非直接功能面如
- 可動態擴充規模來支援不同量級的需求
- 不論發生任何錯誤問題，使用者提交過的 Job 資訊都不能遺失
- 非同步設計，使用者遞交 Job 後就可以繼續別的工作， Job 完成後會主動通知使用者
有了功能面的需求，接下來就是數量大小的需求，譬如該架構要可以達到每秒 1000 個 Job(1000QPS), 從這些需求下去估算大概需要多少 CPU 以及多少 Memory，同時這些數量還可以滿足功能面的需求，譬如每個 Job 可以運行最多五分鐘。
所以也許會得到需要 10,000 台的 (16C) 機器，以及 100 台(16GB) 的機器來提供服務 基本的運算可以快速的理解該需求到底需不需要分散式的架構來處理，本文的範例資料量就很明顯是 scale up 沒有辦法完成的。
接下來就基於分散式的架構去設計相關架構，包含如
- Load Balancer
- Backend
- DB
- Job scheduler
- Job Executor
- Queue
- File system
逐步的規劃這些架構，並且探討彼此元件之間的溝通方式，這些方式是如何互相組合來滿足功能面/非功能面的需求
詳細需求可以參考全文