最初是由ebay提出的。
核心是把大事務轉變為小事務，邏輯如下：
舉例說明：我拿100元去買一瓶水
1. 當你扣錢的時候，你需要在你扣錢的伺服器上新增加乙個本地訊息表，你需要把你扣錢和減去水的庫存寫入到本地訊息表，放入同乙個事務(依靠資料庫本地事務保證一致性）。
2. 這個時候有個定時任務去輪詢這個本地事務表，把沒有傳送的訊息，扔給商品庫存伺服器，叫它減去水的庫存，到達商品伺服器之後，這時得先寫入這個伺服器的事務表，然後進行扣減，扣減成功後，更新事務表中的狀態。
3. 商品伺服器通過定時任務掃瞄訊息表或者直接通知扣錢伺服器，扣錢伺服器在本地訊息表進行狀態更新。
4. 針對一些異常情況，定時掃瞄未成功處理的訊息，進行重新傳送，在商品伺服器接到訊息之後，首先判斷是否是重複的。
如果已經接收，再判斷是否執行，如果執行在馬上又進行通知事務；如果未執行，需要重新執行由業務保證冪等，也就是不會多扣一瓶水。
本地訊息佇列是 base 理論，是最終一致模型，適用於對一致性要求不高的情況。實現這個模型時需要注意重試的冪等。
訊息積壓 訊息丟失解決方案
問題本質都在於你的消費端可能出了問題，不消費或消費的太慢！更可怕的是由於積壓時間太長，導致如果起初還設定了ttl後失效了怎麼辦？其實資料積壓的問題是架構設計不合理。丟失的資料是通過日誌找回來,如果日誌也找不到了 那就沒招了 一般這時，只能操作臨時緊急擴容了，具體操作步驟和思路如下 先修復consum...
Android訊息推送解決方案
怎麼定位gps座標佔時不考慮，我們來分析下服務端打折優惠資訊是怎麼推送給手機客戶端的。一 訊息推送基礎 如何使客戶端能夠實時的收到伺服器的訊息和通知，總體來說有兩種方式，第一種是客戶端使用pull 拉 的方式，就是隔一段時間就去伺服器上獲取一下資訊，看是否有更新的資訊出現。第二種就是 伺服器使用pu...
RocketMQ訊息丟失解決方案 事務訊息
上篇文章，王子通過乙個小案例和小夥伴們一起分析了一下訊息是如何丟失的，但沒有提出具體的解決方案。我們已經知道發生訊息丟失的原因大體上分為三個部分 1.生產者傳送訊息到mq這一過程導致訊息丟失 2.mq自己發生故障導致訊息丟失 3.消費者拿到訊息後，由於操作不當導致訊息丟失 接下來我們就針對第一種情況...