[徵文] 系統設計: 如何取消正在執行的工作任務

看板Soft_Job作者 (小惡魔)時間1年前 (2023/01/01 09:39), 1年前編輯推噓1(2推 1噓 49→)
留言52則, 12人參與, 1年前最新討論串1/1
文字教學: https://bit.ly/3jFMwvS 教學影片: https://bit.ly/3WI0Wdx 範例程式: https://bit.ly/3Z0U6Bt 系統架構圖: https://i.imgur.com/VZyfv0M.png
本篇來聊聊『如何取消正在執行的工作任務』，當系統內有需要處理比較久或較多資源的 任務，肯定會將這些任務丟到其他機器再執行，執行過程如果需要取消，會經過如上圖幾 個步驟。先假設中間的過程不透過 Message Queue 機制，而是兩個服務進行溝通透過 RESTful 或 gRPC 方式。 ## 使用情境 可以看到步驟一是 worker 會先發請求到後端服務，詢問目前正在執行的任務是否取消， 這邊可以用一個長連接持續 30 秒或 1 分鐘才斷線。步驟二是 User 從 Web UI 端按下 取消的按鈕。步驟三是後端服務接受到取消任務的請求，就回覆 Worker 到請求執行取消 任務。 大家可以想看看此情境該如何設計流程，先不考慮多台後端服務的情境，也不考慮使用 Message Queue 的方式來實作。也許大家有想到一種方式，就是當使用者按下取消時 (到 步驟三)，後端服務將此任務的狀態改成取消。而 Worker 每次來詢問狀態 (步驟一)，後 端就再查詢一次就可以了 (步驟四)，這方式也沒有不對，只是即時性效果比較差，如果 是每 30 秒輪詢一次，就有可能 30 秒後才能取消任務，輪詢時間設定很短，又會造成過 多不必要的連線請求。除了這種方式外，還有沒有其他方式可以不需要查詢資料庫就可以 即時讓 Worker 知道目前任務狀態。 目前先講單機版解法，非常適用於要將服務部署在不同團隊內。 ## 心得 本篇最主要是要用 Go 語言的 Channel 特性來處理兩個服務之間的溝通機制，大家可能 想到的解法就是用 Message Queue 來處理，但是有時候把架構想的更簡單一點，用 Go 語言的特性來處理，那就減少一個服務的維運，未來要將此架構轉換到其他平台就會更簡 單，其他部門有需求會是將整套服務架設在不同團隊內，這時候架構越簡單，除錯時間會 越短。 -- AppleBoy Blog: http://blog.wu-boy.com -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.110.136.13 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1672537150.A.DD7.html ※ 編輯: appleboy46 (123.110.136.13 臺灣), 01/01/2023 10:05:18
→
01/01 10:12, 1年前 , 1F
mq夠簡單了吧... 要轉換到其他地方也不難
01/01 10:12, 1F
→
01/01 10:58, 1年前 , 2F
火山表示___
01/01 10:58, 2F
→
01/01 12:01, 1年前 , 3F
..哪個語言沒內建mq
01/01 12:01, 3F
推
01/01 13:01, 1年前 , 4F
樓上那篇怎麼刪文了
01/01 13:01, 4F
→
01/01 14:17, 1年前 , 5F
mq外部化可以讓上下游達到stateless
01/01 14:17, 5F
→
01/01 14:19, 1年前 , 6F
subscriber每個語言都有 不太會自己實作多少秒觀察一次
01/01 14:19, 6F
→
01/01 14:24, 1年前 , 7F
除非服務很簡單,不然用外部mq對維護營運上比較容易
01/01 14:24, 7F
→
01/02 06:56, 1年前 , 8F
感覺只是為了寫而寫....
01/02 06:56, 8F
噓
01/02 09:48, 1年前 , 9F
語言dependent又不scalable，算什麼系統設計？隨便
01/02 09:48, 9F
→
01/02 09:48, 1年前 , 10F
哪個mq維護成本也比維護這土炮架構好
01/02 09:48, 10F
→
01/03 07:46, 1年前 , 11F
MQ 設計好多了吧
01/03 07:46, 11F
→
01/04 11:50, 1年前 , 12F
用 MQ 處理長時間的任務，可能會遇到底下問題
01/04 11:50, 12F
→
01/04 11:51, 1年前 , 13F
1. 如何取得目前任務的狀態？
01/04 11:51, 13F
→
01/04 11:51, 1年前 , 14F
2. 如何設定任務超時機制？
01/04 11:51, 14F
→
01/04 11:52, 1年前 , 15F
3. 如何跨服務取消任務？
01/04 11:52, 15F
→
01/04 11:52, 1年前 , 16F
4. 當 Worker 失去連線或不正常關閉，該如何讓 Task
01/04 11:52, 16F
→
01/04 11:52, 1年前 , 17F
可以重新執行？
01/04 11:52, 17F
→
01/04 11:52, 1年前 , 18F
5. 當有多台 Server + 多台 Worker 時，該如何配送任
01/04 11:52, 18F
→
01/04 11:53, 1年前 , 19F
務及取消任務？
01/04 11:53, 19F
→
01/04 22:12, 1年前 , 20F
..你沒用過mq吧 不然應該不會問4&5
01/04 22:12, 20F
→
01/04 22:15, 1年前 , 21F
別說task派送和取消了 現在還有跨服務交易但不綁連線
01/04 22:15, 21F
→
01/04 22:18, 1年前 , 22F
可以查saga pattern.
01/04 22:18, 22F
→
01/04 22:30, 1年前 , 23F
後面worker達到stateless很基本 就算土砲應該也不該擔心
01/04 22:30, 23F
→
01/04 22:32, 1年前 , 24F
失去連線或當掉或不正常關閉 就算你直接kill-9也可以
01/04 22:32, 24F
→
01/04 23:14, 1年前 , 25F
直接查async request reply 或直接查go原始碼 你會發現
01/04 23:14, 25F
→
01/04 23:15, 1年前 , 26F
裡面一定會有queue. 你只是享受別人封裝好的
01/04 23:15, 26F
→
01/04 23:31, 1年前 , 27F
原po需要好好了解系統設計 人家如果問你"如何取消正在執
01/04 23:31, 27F
→
01/04 23:31, 1年前 , 28F
行的工作任務" 你在面試中會被炮到你完全無法講答案
01/04 23:31, 28F
→
01/04 23:31, 1年前 , 29F
因為你回答的不是系統設計
01/04 23:31, 29F
→
01/04 23:32, 1年前 , 30F
*你在面試中"這樣答"會被炮到你完全無法講答案
01/04 23:32, 30F
→
01/04 23:33, 1年前 , 31F
你這題答案所對應的問題是: 如何實作一個MQ來實現基本的
01/04 23:33, 31F
→
01/04 23:34, 1年前 , 32F
工作任務取消" 多注意點就好 感覺你沒面試過系統設計
01/04 23:34, 32F
→
01/04 23:34, 1年前 , 33F
題目 或者你面試的公司比較low 不知道甚麼是系統設計
01/04 23:34, 33F
→
01/04 23:36, 1年前 , 34F
另外有認真做過碩論的話 不應該發生妳這樣的問題就是
01/04 23:36, 34F
→
01/04 23:38, 1年前 , 35F
你的標題跟本文如果對應到碩論題目跟本文(這邊不論這東
01/04 23:38, 35F
→
01/04 23:39, 1年前 , 36F
西是否適合作為一個碩論題目) 你早就被教授炮到台上回家
01/04 23:39, 36F
→
01/04 23:39, 1年前 , 37F
哭也不是 不哭也不是。。。百分之百被炮的
01/04 23:39, 37F
→
01/05 10:59, 1年前 , 38F
現在刷leet code 才是高手保證.系統設計? 那是啥
01/05 10:59, 38F
→
01/05 14:01, 1年前 , 39F
其實除了那幾間大公司，現在考leetcode沒那麼普遍
01/05 14:01, 39F
→
01/05 14:01, 1年前 , 40F
senior以上都還滿注重系統設計的
01/05 14:01, 40F
→
01/05 15:21, 1年前 , 41F
了解了，我在把標題定義清楚些
01/05 15:21, 41F
→
01/05 15:21, 1年前 , 42F
感謝 @peter98 及 @alan3100 建議
01/05 15:21, 42F
推
01/06 00:07, 1年前 , 43F
上述 12345 MQ, 純 http, 純 socket, 純 channel 或混用
01/06 00:07, 43F
→
01/06 00:08, 1年前 , 44F
應該都做得到, 只是實作花的時間跟運行成本可能有差
01/06 00:08, 44F
→
01/06 00:09, 1年前 , 45F
它們都只是通訊手段, 只是有的單向有的雙向, 有的幫你排
01/06 00:09, 45F
→
01/06 00:11, 1年前 , 46F
好序, 有的提供端點識別或方便的廣播, 或自動重送重試
01/06 00:11, 46F
→
01/06 00:13, 1年前 , 47F
需要實現的其實也只有 1. 對特定 server/worker 發送
01/06 00:13, 47F
→
01/06 00:14, 1年前 , 48F
2. 廣播, 3. 針對特定 task 下指令 三件事
01/06 00:14, 48F
→
01/06 00:16, 1年前 , 49F
系統設計是很多方法都做得到再去做取捨, 如果很明確只有
01/06 00:16, 49F
→
01/06 00:16, 1年前 , 50F
特定方法才做得到的事情就不用設計了, 反正沒得選
01/06 00:16, 50F
→
01/06 09:49, 1年前 , 51F
公司內部特定環境，沒辦法使用 MQ 等相關 Component
01/06 09:49, 51F
→
01/06 09:50, 1年前 , 52F
所以才有了這些方法跟機制來實現。
01/06 09:50, 52F
‣ 更多 appleboy46 的文章
文章代碼(AID): #1ZiEG-tN (Soft_Job)