溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文小編為大家詳細介紹“微服務中可靠消息服務如何實現”，內容詳細，步驟清晰，細節處理妥當，希望這篇“微服務中可靠消息服務如何實現”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。
分布式事物解決方式有很多，網上博客也有一大堆 總結一般有如下兩種
1 剛性分布式事務，兩階段提交 強一致性
2 柔性分布式事務 最大努力提交 ,tcc,可靠消息服務
首先解決分布式事務前提保障：接口必須冪等性，防止消息重復發送對業務影響
如上圖
開始執行 比如：try{if(prepare()) { //預發送階段doService(); //執行業務邏輯updateMsgStatus();//更新消息為確認狀態}}
1 預發送消息，try階段，如果預發送消息失敗了，業務還未執行，所以 系統A，B還是一致性的 不需要處理
這一點容易理解
2 預發送消息成功了，開始執行業務邏輯。執行成功 更新預發送消息轉態為確認發送。如果 此時 業務邏輯執行失敗了，那預發送消息就不會跟新狀態，此時消息確認系統就開啟工作，到業務系統1上回查此消息狀態，此時發現業務執行失敗了，就更新預發送狀態至失敗狀態。
3 如果此時 業務執行成功了消息也被更新成確認發送了 那就ok 完美。如果消息更新失敗，還是由消息確認系統回查轉態 更新此消息被刪除狀態還是確認發送狀態。
4 消息者開始消費
1> 比如消費失敗了，此時產生不一致， 消息恢復系統檢測消息狀態，重新發送消息
2>如果執行業務失敗了，此消息也就不會被確認了，還是由消息恢復系統檢測消息狀態，重新發送消息
3>如果ask失敗了，還是以上邏輯重新發送上訴重新發送當然有次數限制，不能一直發送，超過最大次數就要進入死信隊列，等待人工干預了
4> ask成功，消息也就成功消費了，完美，解決了消息可靠服務
這個比較簡單 ，將失敗的消息重復提交，實時性比較弱的一些場景，確保消息推送成功。
比如交易完成推送第三方消息。 此時可以使用努力提交
讀到這里，這篇“微服務中可靠消息服務如何實現”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
