本方案基於外部事件表（mysql）+mq（activemq）+springcloud方式提供事務型訊息傳送。此方案並不依賴特定的事件表及mq，tps受限時可進行替換。主要應用在事務中包含的重介面、第三方系統呼叫等，以實現非同步化，保證最終一致性。因為是非同步呼叫，所以介面限制為不能有返回值。為了記錄完整的呼叫日誌鏈，整個過程中注意傳遞請求日誌id。
在springcloud中遠端呼叫預設協議為http，客戶端實現是使用feign。在遠端呼叫介面的定義處（@feignclient）增加乙個註解（如@transactionalmessage）標記該遠端呼叫支援非同步事務訊息。對@transactionalmessage標記的方法做乙個切面攔截，把feignclient的請求資訊（request）預存到事件表中。如果此處有任何異常或有開關控制，此處可直接執行遠端呼叫。如無異常則執行訊息傳送，忽略本身的遠端呼叫。
監聽到before_commit時修改預存事件狀態為已提交待傳送狀態，此操作還在包含在事務當中，所以可儲存狀態的一致性。
監聽到after_commit時把與當前事務關聯的事務訊息傳送到mq中通知執行遠端方法呼叫。
監聽到after_rollback時回滾預存的事件表資料。
提供乙個單獨的服務，來處理事件表裡的遠端呼叫。需處理mq的通知以及定時查詢事件表裡可重試狀態的資料，還需注意重複訊息，保證冪等性。還原事件表裡記錄的request，request記錄了請求引數或請求體、請求頭、請求位址（網域名稱部分是由應用名替代）。注入feign的client客戶端執行request即可。此處需判斷執行是否成功，除了判斷http呼叫是否成功，還需判斷業務是否執行成功（所有介面需統一返回乙個狀態碼來標明是否正常執行）。如果執行成功則刪除事件表中對應的資料，否則回滾，等待下次重試。
Kafka訊息可靠性
如果mq沒有類似資料庫事務結構和保證，是不可能達到訊息投遞100 可靠的，極端情況下訊息投遞要麼丟失或重複。下面咋們從producer，broker，consumer的角度分析一下kafka中會出現哪些情況。目前生產者傳送訊息 request.required.acks 有三種方式。acks 0 p...
二 訊息可靠性
可以在下面兩個地方進行設定 messageproducer producer session.createproducer queue producer.setdeliverymode deliverymode non persistent for int i 0 i 100 i 2.1 普通top...
十二 訊息可靠性
持久化可以提高rabbitmq的可靠性，以防在異常情況 重啟 關閉 右機等 下的資料丟失。rabbitmq的持久化分為三個部分 持久化客戶端 public class send catch ioexception e catch timeoutexception e finally catch io...