這篇寫好放了半年了，現在才想到要貼出來…

這題是前陣子碰到的問題，解決過程中按照慣例，順手寫了 PoC code 來驗證解法，事後就整理一下寫了這篇。

當你的系統擴大到 7 x 24, 資料量大到某個程度, 系統反應速到開始要求到即時回應的時候, 什麼環節都開始要求要 HA, 系統架構開始走向 cloud native, 系統的回應都要求要即時處理時, 你會發現很多問題的處理方式都完全不同了。

這篇講的就是需要及時處理當下接收到的 message, 同時又期待能按照順序處理 (如果是存在 DB 的話，select + order by 就搞定了)，而越是即時，越沒有那個空間讓你等到接收完畢再排序, 即時的 message 是一筆一筆接收到的，並且接收到後就得立即處理。如果傳輸過程中時間相近的兩筆順序錯了, 差了一秒, 先後次序顛倒, 這時你該怎麼處理?

你可以停下來確定都收到了再排序處理，是一種方法；只是這樣就 “不夠即時” 了… 你可以收到就立刻處理, 但是有些任務一旦順序錯了你也無法回收了 (例如發出錯誤的通知, 或是算錯點數)。兩者該如何取得平衡? 更重要的是有方法能精確的處理嗎? 串流的資料處理方式, 有別於傳統的資料庫處理模式, 你必須從通訊的層面就解決他才行。

這篇我就是想聊聊這背後的處理模型，也讓我回想到大學時代念網路通訊技術的時候，網路封包的處理，TCP / UDP 的差異，其實也在處理類似的問題。果然資訊科學的領域基礎都類似啊，就像先前處理排隊機制，其實背後也跟網路設備的 QoS 原理類似… 這篇我就用 Hi level 的角度, 用 C# 嘗試實做一個簡單的 re-order message process 的框架, 來說明你該用什麼架構來面對這需求吧..

– ( 雖說是面試題, 我倒是還沒機會在面試時聊到這個層次的白板題 XDD, 有興趣的可以來聊看看 :D )

https://columns.chicken-house.net/2023/10/01/reorder/