阿里消息中間件ONS消息重複問題和事物問題(三)

產生的緣由:網絡不可達問題。安全

網絡超時以後咱們能夠作的只有兩件事,1 中止(回滾,但對於系統來講影響特別大) 2 繼續(另發送到別的服務消費端)網絡

通常咱們採用第二種處理方式,可是要通過網絡,必然會出現消息重複問題。併發

最好的解決方法是:異步

剛好不須要——冪等操做高併發

S * S = S (某個操做無論重複多少次,結果都同樣)。設計

冪等消息去重:日誌

  • 保證有個惟一ID標記每一條消息
  • 保證消息處理成功與去重表日誌同事出現

代價:去重代價是去重日誌的寫入,數據校驗,多臺機器對去重表的維護。事件

  • ONS消息與事物轉帳設計難點:
  1. 如何保證消息發送與Bob帳戶減錢同時成功或同時失敗?
  2. 消息處理超時的解決?
  3. 消息處理失敗如何解決?

儘可能保持消息接受者的冪等性擴展

可是對於非冪等的消息消費端:要記錄日誌表,內次執行時進行日誌校驗。配置

  1. 當消息接收者處理失敗時,能挽回失敗的方法之一是系統,可是系統回滾的開銷每每是很大的。
  2. 還有一種方式是人工處理,當事件發生的機率 比 寫代碼挽回失敗Bug的機率還要小,這樣咱們就須要考慮是否使用人工處理了。
  3. 利用努力送達模型,失敗後再從新發往mq中,從新進行消費,儘可能保證數據處理成功。努力送達模型是系統但願來進行這樣的設計的。

 

小結:

  • 消息系統:解耦 異步 最終一致性 並行
  • ONS 和其餘消息系統不同的部分:高吞吐量 高併發。
  • 面向於失敗的系統: 消息安全性, 消息堆積能力 消息吞吐量 和 延遲 (crash崩潰)
  • 系統的關鍵特性: topic、tag、消息組(訂閱組:動態將消息經過一個配置文件配置組的名字,動態的歸屬到某一個組內,能保證消息發送者 和 消息訂閱者能夠自動的擴展 或 減容)
  • 代價:消息重複問題,消息亂序問題。
  • 支持事物的消息模式
相關文章
相關標籤/搜索