大部分內容**:
這裡是記錄下另乙個解決方案，採用訊息表跟mq來完成分布式事務,這個方案還是最終一致性
基本思路就是：
訊息生產方，需要額外建乙個訊息表，並記錄訊息傳送狀態。訊息表和業務資料要在乙個事務裡提交。實現時為了簡單，可以只是增加乙個字段。新增欄位會跟業務強耦合，新增表處理起來不同交易資料可以通用處理。不過因為訊息表跟業務需要在乙個事務裡，所以儲存耦合在所難免。
訊息消費方，需要處理這個訊息，並完成自己的業務邏輯。此時如果本地事務處理成功，那傳送給生產方乙個confirm訊息，表明已經處理成功了。如果處理失敗，該訊息還是需要放回mq的。如果mq支援重試，那就省事兒了。如果不支援，可以考慮把該訊息放回隊尾或另建乙個佇列特殊處理。當然非要處理成功才能繼續，那只能block在這條訊息了（估計一般人不會這麼做）。kafka lowlevel介面是支援自己設定offset的，所以可以實現block。
生產方定時掃瞄本地訊息表，把還沒處理完成的訊息由傳送一遍。如果有靠譜的自動對賬補賬邏輯，其實這一步也可以省略。在實踐中，丟訊息或者下游處理失敗這種場景還是非常少的。這裡要看業務上能不能容忍不一致到乙個對賬補賬週期。
這裡的mq假如採用的是rabbitmq，因為rabbitmq可以設定沒收到confirm時，訊息依然儲存在佇列裡，所以上面第2點提到的需要將訊息放回到mq，對rabbitmq來說，是不需要的。
總結上面說的思路，舉個例子，乙個簡單的下單流程，包括生成訂單，扣庫存，扣優惠券積分（如有），新增日誌
這四步對應的應用在四個伺服器裡
另下面的重試都要實現冪等
第一步：生成訂單，在執行完生成訂單邏輯後，向mq傳送一條訊息（處理扣庫存的邏輯）
假設傳送後，沒收到mq的ack，我覺得可以重試3次，3次都不成功（指沒收到ack），則生成一條訊息表記錄，有兩個字段，訂單id，狀態字段，（這裡設為0）設為未傳送成功，然後定時器會定時去掃瞄訊息表，把那些沒有傳送成功地訊息再傳送一次
生成訂單和給mq傳送訊息和往訊息表生成訊息都是在同乙個事務裡面，訊息表跟訂單表在同乙個事務
第二步：mq收到訊息後，開始執行扣庫存的邏輯，執行後向mq傳送一條訊息（處理扣優惠卷積分的邏輯）
假設傳送後，沒收到mq的ack，我覺得可以重試3次，3次都不成功（指沒收到ack），則生成一條訊息表記錄，有兩個字段，訂單id，狀態字段，（這裡設為0）設為未傳送成功，然後定時器會定時去掃瞄訊息表，把那些沒有傳送成功地訊息再傳送一次
扣庫存和給mq傳送訊息和往訊息表生成訊息都是在同乙個事務裡面，訊息表跟庫存表在同乙個事務
以此類推
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...
分布式之分布式事務
被人問到分布式事務，之前學rabbitmq 的時候學到過rabbitmq 高階的事務，因為沒有用過，所有沒有回答好。這裡總結一下。1.單機版事務。事務的四大特性 acid a.原子性 b.一致性 c.隔離性 d.永續性 單機事務可以通過設定事務的隔離級別 參見spring 的事務隔離級別 2.分布式...