（一）、基于可靠消息的最終一致性方案概述

· 實現(xiàn)：業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)提交之前，向?qū)崟r消息服務(wù)請求發(fā)送消息你弦，實時消息服務(wù)只記錄消息數(shù)據(jù)，而不是真正的發(fā)送燎孟。業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)提交之后禽作，向?qū)崟r消息服務(wù)確認發(fā)送。只有在得到確認發(fā)送指令后揩页，實時消息服務(wù)才會真正發(fā)送旷偿。
· 消息：業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)回滾后，向?qū)崟r消息服務(wù)取消發(fā)送爆侣。消息發(fā)送狀態(tài)確認系統(tǒng)定期找到未確認發(fā)送或者回滾發(fā)送的消息绎秒，向業(yè)務(wù)處理服務(wù)詢問消息狀態(tài)豌注，業(yè)務(wù)處理服務(wù)根據(jù)消息ID或者消息內(nèi)容確認該消息是否有效赶熟。被動方的處理結(jié)果不會影響主動方的處理結(jié)果倦踢，被動方的消息處理操作是冪等操作。
· 成本：可靠的消息系統(tǒng)建設(shè)成本斋陪，一次消息發(fā)送需要兩次請求朽褪，業(yè)務(wù)處理服務(wù)需要實現(xiàn)消息狀態(tài)回查接口。
· 優(yōu)點：消息數(shù)據(jù)獨立存儲无虚，獨立伸縮缔赠，降低業(yè)務(wù)系統(tǒng)和消息系統(tǒng)之間的耦合。對最終一致性時間敏感度較高友题，降低業(yè)務(wù)被動方的實現(xiàn)成本嗤堰。兼容所有實現(xiàn)JMS標準的MQ中間件，確保業(yè)務(wù)數(shù)據(jù)可靠的前提下度宦，實現(xiàn)業(yè)務(wù)的最終一致性踢匣，理想狀態(tài)下是準實時的一致性。

（二）戈抄、TCC事務(wù)補償型方案

· 實現(xiàn)：一個完整的業(yè)務(wù)活動由一個主業(yè)務(wù)服務(wù)于若干的從業(yè)務(wù)服務(wù)組成离唬。主業(yè)務(wù)服務(wù)負責發(fā)起并完成整個業(yè)務(wù)活動。從業(yè)務(wù)服務(wù)提供TCC型業(yè)務(wù)操作划鸽。業(yè)務(wù)活動管理器控制業(yè)務(wù)活動的一致性输莺，它登記業(yè)務(wù)活動的操作戚哎，并在業(yè)務(wù)活動提交時確認所有的TCC型操作的Confirm操作，在業(yè)務(wù)活動取消時調(diào)用所有TCC型操作的Cancel操作嫂用。
· 成本：實現(xiàn)TCC操作的成本較高型凳，業(yè)務(wù)活動結(jié)束的時候Confirm和Cancel操作的執(zhí)行成本。業(yè)務(wù)活動的日志成本嘱函。
· 使用范圍：強隔離性甘畅，嚴格一致性要求的業(yè)務(wù)活動。適用于執(zhí)行時間較短的業(yè)務(wù)往弓，比如處理賬戶或者收費等等疏唾。
· 特點：不與具體的服務(wù)框架耦合，位于業(yè)務(wù)服務(wù)層亮航，而不是資源層荸实，可以靈活的選擇業(yè)務(wù)資源的鎖定粒度匀们。TCC里對每個服務(wù)資源操作的是本地事務(wù)缴淋，數(shù)據(jù)被鎖住的時間短，可擴展性好泄朴，可以說是為獨立部署的SOA服務(wù)而設(shè)計的重抖。

（三）、最大努力通知型

· 實現(xiàn)：業(yè)務(wù)活動的主動方在完成處理之后向業(yè)務(wù)活動的被動方發(fā)送消息祖灰，允許消息丟失钟沛。業(yè)務(wù)活動的被動方根據(jù)定時策略，向業(yè)務(wù)活動的主動方查詢局扶，恢復丟失的業(yè)務(wù)消息恨统。
· 約束：被動方的處理結(jié)果不影響主動方的處理結(jié)果。
· 成本：業(yè)務(wù)查詢與校對系統(tǒng)的建設(shè)成本三妈。
· 使用范圍：對業(yè)務(wù)最終一致性的時間敏感度低畜埋。跨企業(yè)的業(yè)務(wù)活動畴蒲。
· 特點：業(yè)務(wù)活動的主動方在完成業(yè)務(wù)處理之后悠鞍，向業(yè)務(wù)活動的被動方發(fā)送通知消息。主動方可以設(shè)置時間階梯通知規(guī)則模燥，在通知失敗后按規(guī)則重復通知咖祭，知道通知N次后不再通知。主動方提供校對查詢接口給被動方按需校對查詢蔫骂，用戶恢復丟失的業(yè)務(wù)消息么翰。
· 適用范圍：銀行通知，商戶通知辽旋。
三浩嫌、基于可靠消息的最終一致性方案詳解
（一）、消息發(fā)送一致性
消息中間件在分布式系統(tǒng)中的核心作用就是異步通訊、應(yīng)用解耦和并發(fā)緩沖（也叫作流量削峰）固该。在分布式環(huán)境下锅减，需要通過網(wǎng)絡(luò)進行通訊，就引入了數(shù)據(jù)傳輸?shù)牟淮_定性伐坏，也就是CAP理論中的分區(qū)容錯性怔匣。

在上面的情況中纯露，如果業(yè)務(wù)操作成功剿骨，執(zhí)行的消息發(fā)送之前應(yīng)用發(fā)生故障，消息發(fā)送不出去埠褪，導致消息丟失浓利，將會產(chǎn)生訂單系統(tǒng)與會計系統(tǒng)的數(shù)據(jù)不一致。如果消息系統(tǒng)或者網(wǎng)絡(luò)異常钞速，也會導致消息發(fā)送不出去贷掖，也會造成數(shù)據(jù)不一致。
如何知道 消息是否被接收 而不是丟失呢

（二）爽丹、保證消息一致的變通做法

1. 發(fā)送消息：主動方現(xiàn)將應(yīng)用把消息發(fā)給消息中間件筑煮，消息狀態(tài)標記為“待確認”狀態(tài)。
2. 消息中間件收到消息后粤蝎，把消息持久化到消息存儲中真仲，但是并不影響被動方投遞消息。
3. 消息中間件返回消息持久化結(jié)果初澎，主動方根據(jù)返回的結(jié)果進行判斷如何進行業(yè)務(wù)操作處理：
   a. 失斀沼Α：放棄執(zhí)行業(yè)務(wù)操作處理，結(jié)束碑宴，必要時向上層返回處理結(jié)果软啼。
   b.成功：執(zhí)行業(yè)務(wù)操作處理。
4. 業(yè)務(wù)操作完成后延柠，把業(yè)務(wù)操作結(jié)果返回給消息中間件祸挪。
5. 消息中間件收到業(yè)務(wù)操作結(jié)構(gòu)后，根據(jù)業(yè)務(wù)結(jié)果進行處理：
   a. 失斦昙洹：刪除消息存儲中的消息贿条，結(jié)束。
   b. 成功：更新消息存儲中的消息狀態(tài)為“待發(fā)送”榜跌，然后執(zhí)行消息投遞闪唆。
6. 前面的正向流程都成功之后盅粪，向被動方應(yīng)用投遞消息钓葫。但是在上面的處理流程中，任何一個環(huán)節(jié)都有可能出現(xiàn)問題票顾。

（三）础浮、常規(guī)MQ消息處理流程和特點
· 常規(guī)的MQ隊列處理流程無法實現(xiàn)消息的一致性。

· 投遞消息的本質(zhì)就是消息消費奠骄，可以細化豆同。

（四）、消息重復發(fā)送問題和業(yè)務(wù)接口冪等性設(shè)計

對于未確認的消息含鳞，采用按規(guī)則重新投遞的方式進行處理影锈。
對于以上流程，消息重復發(fā)送會導致業(yè)務(wù)處理接口出現(xiàn)重復調(diào)用的問題蝉绷。
消息消費過程中消息重復發(fā)送的主要原因就是消費者成功接收處理完消息后鸭廷，消息中間件沒有及時更新投遞狀態(tài)導致的。
如果允許消息重復發(fā)送熔吗，那么消費方應(yīng)該實現(xiàn)業(yè)務(wù)接口的冪等性設(shè)計辆床。

（五）、本地消息服務(wù)方案

· 實現(xiàn)思路：
主動方應(yīng)用系統(tǒng)通過業(yè)務(wù)操作完成業(yè)務(wù)數(shù)據(jù)的操作桅狠，在準備發(fā)送消息的時候?qū)⑾⒋鎯υ谥鲃臃綉?yīng)用系統(tǒng)一份讼载，另一份發(fā)送到實時消息服務(wù)
被動方應(yīng)用系統(tǒng)監(jiān)聽實時消息系統(tǒng)中的消息轿秧，當被動方完成消息處理后通過調(diào)用主動方接口完成消息確認主動方接收到消息確認以后刪除消息數(shù)據(jù)。
通過消息查詢服務(wù)查詢到消息被接收之后再規(guī)定的時間內(nèi)沒有返回ACK確認消息就通過消息恢復系統(tǒng)重新發(fā)送消息咨堤。
· 優(yōu)點：
消息的時效性比較高
從應(yīng)用設(shè)計的角度實現(xiàn)了消息數(shù)據(jù)的可靠性菇篡，消息數(shù)據(jù)的可靠性不依賴于MQ中間件，弱化了對MQ中間件特性的依賴一喘。
方案輕量級逸贾，容易實現(xiàn)。
· 缺點：
與具體的業(yè)務(wù)場景綁定津滞，耦合性強铝侵，不可以共用。
消息數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)同步触徐，占用業(yè)務(wù)系統(tǒng)資源咪鲜。
業(yè)務(wù)系統(tǒng)在使用關(guān)系型數(shù)據(jù)庫的情況下消息服務(wù)性能會受到關(guān)系型數(shù)據(jù)庫的并發(fā)性能限制。

（六）撞鹉、獨立消息服務(wù)方案

· 實現(xiàn)思路：
預發(fā)送消息：主動方應(yīng)用系統(tǒng)預發(fā)送消息疟丙，由消息服務(wù)子系統(tǒng)存儲消息，如果存儲失敗鸟雏，那么也就無法進行業(yè)務(wù)操作享郊。如果返回存儲成功，然后執(zhí)行業(yè)務(wù)操作孝鹊。
執(zhí)行業(yè)務(wù)操作：執(zhí)行業(yè)務(wù)操作如果成功的時候炊琉，將業(yè)務(wù)操作執(zhí)行成功的狀態(tài)發(fā)送到消息服務(wù)子系統(tǒng)。消息服務(wù)子系統(tǒng)修改消息的標識為“可發(fā)送”狀態(tài)又活。
發(fā)送消息到實時消息服務(wù)：當消息的狀態(tài)發(fā)生改變的時候苔咪，立刻將消息發(fā)送到實時消息服務(wù)中。接下來柳骄，消息將會被消息業(yè)務(wù)的消費端監(jiān)聽到团赏，然后被消費。
消息狀態(tài)子系統(tǒng)：相當于定時任務(wù)系統(tǒng)耐薯，在消息服務(wù)子系統(tǒng)中定時查找確認超時的消息舔清，在主動方應(yīng)用系統(tǒng)中也去定時查找沒有處理成功的任務(wù)，進行相應(yīng)的處理曲初。
消息消費：當消息被消費的時候体谒，向?qū)崟r消息服務(wù)發(fā)送ACK，然后實時消息服務(wù)刪除消息复斥。同時調(diào)用消息服務(wù)子系統(tǒng)修改消息為“被消費”狀態(tài)营密。
消息恢復子系統(tǒng)：當消費方返回消息的時候，由于網(wǎng)絡(luò)中斷等其他原因?qū)е孪]有及時確認目锭，那么需要消息恢復子系統(tǒng)定時查找出在消息服務(wù)子系統(tǒng)中沒有確認的消息评汰。將沒有被確認的消息放到實時消息服務(wù)中纷捞，進行重做，因為被動方應(yīng)用系統(tǒng)的接口是冪等的被去。
· 優(yōu)點：
消息服務(wù)獨立部署主儡，獨立維護，獨立伸縮惨缆。
消息存儲可以按需選擇不同的數(shù)據(jù)庫來集成實現(xiàn)糜值。
消息服務(wù)可以被相同的的使用場景使用，降低重復建設(shè)服務(wù)的成本坯墨。
從分布式服務(wù)應(yīng)用設(shè)計開發(fā)角度實現(xiàn)了消息數(shù)據(jù)的可靠性寂汇，消息數(shù)據(jù)的可靠性不依賴于MQ中間件，弱化了對MQ中間件特性的依賴捣染。
降低了業(yè)務(wù)系統(tǒng)與消息系統(tǒng)之間的耦合骄瓣，有利于系統(tǒng)的擴展維護。
· 缺點：
一次消息發(fā)送需要兩次請求耍攘。
主動方應(yīng)用系統(tǒng)需要實現(xiàn)業(yè)務(wù)操作狀態(tài)的校驗與查詢接口榕栏。