架構師之路再刷一下思路記錄 5

訊息匯流排架構

什麼時候使用mq：跨程序通訊傳遞訊息；解耦；如果呼叫方實時依賴執行結果就不適用；加入mq系統更複雜，傳遞路徑更長，訊息不丟不重難以同時保證

資料驅動的任務依賴：cron人工排執行時間表：這個似不似有點傻；用mq，step1完了發個訊息說完了，task2訂閱收到step1完了就開始，以此類推；

mq實現延遲訊息：比如48小時後自動評價

常見方案：啟動乙個cron定時任務，每小時跑一次，將完成時間超過48小時的訂單取出，置為5星，並把評價狀態置為已評價

select oid from t_order where finish_time > 48hours and status=0;
update t_order set stars=5 and status=1 where oid in[…];

如果資料量大，需要分頁查詢分頁更新，所以輪詢效率低，已經執行過的還會再被掃，時效性不夠好

好的方案：

環形佇列，本質是個陣列，環上每個slot是乙個set，同時啟動乙個timer每隔1s，在環形佇列中移動一格，有乙個current index指標來標誌正在檢測的slot

task結構中包含兩個重要屬性，cycle-num：當current index第幾圈掃到這個slot時，執行任務；task-function：需要執行的任務指標

假設環3600個slot，每秒掃瞄乙個slot，需要3610秒後執行的延時訊息到達後，發現當前index指向1，經過計算，應該存在11格仔並且應該在一圈之後執行，每秒移動到乙個新的slot，看set中每個task的cycle-num是不是0，如果不是0，則經過減1，如果是0，則執行並刪除該task

此方案好處是無需輪詢全部訂單，效率高，乙個訂單任務只執行一次，時效性好

訊息的必達：落地 + 訊息超時、重傳、確認

傳送方 -> mq -> 接收方

傳送，mq伺服器落地訊息，應答成功； mq伺服器傳送訊息給訂閱端，訂閱端回覆伺服器，伺服器收到確認，將落地訊息刪除，完成一次可靠的投遞

冪等對於服務端對客戶端的確認丟失，導致客戶端不斷重發，避免服務端收到訊息後重複落地，需要對每條訊息生成全域性唯一並且業務無關的inner-msg-id，由mq生成並且業務無關，作為去重和冪等的依據

客戶端ack消費到服務端未成功，服務端多次推送訊息給消費端，解決方法是業務訊息體系中有乙個biz-id，作為去重和冪等依據，對同乙個業務場景，全域性唯一，由業務訊息傳送方生成，業務相關，對mq透明，由業務訊息消費方負責判重，保證冪等