常見的分布式事務四大解決方案：2pc、tcc、可靠訊息最終一致性、最大努力通知。前三種解決方案我們都分別從理論和實戰兩個維度做了講解。今天我們來說說最大努力通知這個解決方案的理論部分。
先來看看下面這個充值的例子：
互動流程如下：
（1）賬戶系統呼叫充值系統介面發起支付請求。
（2）充值系統完成支付處理向賬戶系統發起充值結果通知。若通知失敗，則充值系統按策略進行重複通。
（3）賬戶系統接收到充值結果通知修改充值狀態。
（4）賬戶系統未接收到通知會主動呼叫充值系統的介面查詢充值結果。
通過上邊的例子我們總結最大努力通知方案的目標是：發起通知方通過一定的機制最大努力將業務處理結果通知到接收方。具體包括以下兩點：
（1）有一定的訊息重複通知機制：因為接收通知方可能沒有接收到通知，此時要有一定的機制對訊息重複通知。
（2）訊息校對機制：如果盡最大努力也沒有通知到接收方，或者接收方消費訊息後要再次消費，此時可由接收方主動向通知方查詢訊息資訊來滿足需求。
（1）解決方案思想不同
可靠訊息一致性，發起通知方需要保證將訊息發出去，並且將訊息發到接收通知方，訊息的可靠性關鍵由發起通知方來保證。
最大努力通知，發起通知方盡最大的努力將業務處理結果通知為接收通知方，但是可能訊息接收不到，此時需要接收通知方主動呼叫發起通知方的介面查詢業務處理結果，通知的可靠性關鍵在接收通知方。
（2）兩者的業務應用場景不同
可靠訊息一致性關注的是交易過程的事務一致，以非同步的方式完成交易。
最大努力通知關注的是交易後的通知事務，即將交易結果可靠的通知出去。
（3）技術解決方向不同
可靠訊息一致性要解決訊息從發出到接收的一致性，即訊息發出並且被接收到。
最大努力通知無法保證訊息從發出到接收的一致性，只提供訊息接收的可靠性機制。可靠機制是：最大努力的將訊息通知給接收方，當訊息無法被接收方接收時，由接收方主動查詢訊息（業務處理結果）。
通過對最大努力通知的理解，我們很容易就想到使用mq的ack機制來實現最大努力通知。
流程如下：
（1）發起通知方使用普通資訊將通知發給mq。
（2）接收通知方監聽 mq，並接收訊息，業務處理完成回應ack。
（3）接收通知方若沒有回應ack則mq會重複通知。（rocketmq會按照間隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知間隔，直到達到通知要求的時間視窗上限。）
（4）接收通知方可通過訊息校對介面來校對訊息的一致性。
流程如下：
（1）發起通知方將通知發給mq。（使用可靠訊息一致方案中的事務訊息保證本地事務與訊息的原子性，最終將通知先發給mq）
（2）通知程式監聽 mq，接收mq的訊息。（若通知程式若沒有回應ack則mq會重複通知）
（3）通知程式通過網際網路介面協議（如http、webservice）呼叫接收通知方案介面，完成通知。（通知程式呼叫接收通知方案介面成功就表示通知成功，即消費mq訊息成功，mq將不再向通知程式投遞通知消
息。）（4）接收通知方可通過訊息校對介面來校對訊息的一致性。
（1）方案1中接收通知方與mq介面，即接收通知方案監聽 mq，此方案主要應用與內部應用之間的通知。
分布式事務解決方案之四 最大努力通知
自學筆記 6.1.什麼是最大努力通知 最大努力通知也是一種解決分布式事務的方案，下邊是乙個是充值的例子 互動流程 1 賬戶系統呼叫充值系統介面 2 充值系統完成支付處理向賬戶系統發起充值結果通知 若通知失敗，則充值系統按策略進行重複通知 3 賬戶系統接收到充值結果通知修改充值狀態。4 賬戶系統未接收...
分布式事務解決方案 最大努力通知以及解決方案
分布式系統中，服務之間的互相呼叫有時候在某些業務場景下，被呼叫者需要將業務處理結果再通知到呼叫者，呼叫者才能繼續完成後續的業務操作，在這種場景下要保證業務的連續性 完整性 最終一致性等，就需要訊息通知的可靠性至關重要。結合以上的分析，最大努力通知就是服務間的訊息通知，要盡可能的設計和使用某些策略手段...
分布式事務（五）之最大努力通知
最大努力通知型 best effort delivery 是最簡單的一種柔性事務，適用於一些最終一致性時間敏感度低的業務，且被動方處理結果不影響主動方的處理結果。典型的使用場景 如銀行通知 商戶通知等。最大努力通知型 best effort delivery 是最簡單的一種柔性事務，適用於一些最終一...