隨著時間的推進,每個人終究都會被放在最適合自己的位子上.
任務調度系統(Task Scheduler / Job Scheduler)這種東西,看起來每家公司都有,用起來都差不多,但只要你認真去看一次原始碼,就會發現每個團隊的取捨都不一樣。
這篇文章不是要告訴你「任務調度是什麼」。網路上的科普文已經太多了。我要講的是:當我們真的坐下來要畫一張架構圖,每一個節點為什麼要這樣選。參考的影片是 s09g 的《system design — 任務調度系統》(約 29 分鐘),我把裡面 12 個章節的取捨整理成一條線,並加上我自己做後端這些年的看法。
我們的場景先講清楚:假設要替一個內部系統(10k 工程師規模)做一個任務調度平台。
WinkHosting 上個月丟了一篇 Server Monitoring with PHP and Bash Scripts,標題一看就是「自己蓋」的派別:被監控端跑一支 Bash,metrics 寫成檔案,curl 丟到中央的 PHP 端點,PHP 把檔案存進 /files。作者 Camilo 自己也在文末補了一句「presentation of information 留給你想像」 — 等於交了一半的解。
這種輕量做法其實很對我的胃口。我手上管的機器不多,但又不想被 SaaS monitor 鎖住資料。所以這篇不是照翻,是把原文照著走一遍,再加...
從 sidecar 模式、Ingestion 架構到倒排索引,一次搞懂集中式日誌系統設計的面試重點
最近看了一支 s09g 的系統設計 Mock Interview,受面者設計「集中式日誌系統」,面試官在 45 分鐘內從 Clarify 一路 DeepDive 到查詢層,把每一層的設計決定都翻過一遍。這類「面試官逐點 feedback」的影片,對準備系統設計面試的人特別有價值——比起「如何設計一個 log system」的教學文,它揭露的是真正的 trade-off 與面試官在意什麼。
這篇整理影片裡面試官挑出的五個關鍵設計決定,包含他自己的「我會怎麼問」與「為什麼這樣...