分佈式事務
若是系統規模較小，數據表都在一個數據庫實例上，上述本地事務方式能夠很好地運行，
可是若是系統規模較大，好比用戶A帳戶表和用戶B帳戶表顯然不會在同一個數據庫實例上，他們每每分佈在不一樣的物理節點上，這時本地事務已經失去用武之地。數據庫
分佈式事務解決方法
兩階段提交(屢次節點間的通訊,事務時間較長,鎖定資源的時間較長,不適合高併發系統)
消息(最終一致性)
數據 在一段時間是不一致的,可是最終可以實現一致性,能夠提升併發量,
好比,如今不少飯店都是小票排號,你點了什麼菜,飯點的時候人不少,不能點了菜,立刻就能上菜,可是你已經排上號了,最終都會給你上菜的.這就是最終的一致性. 很顯然這樣可以提升接待能力.
消息與業務耦合
Begin transaction
update A set amount=amount-10000 where userId=1;
insert into message(userId, amount,status) values(1, 10000, 1);//這裏不直接發送消息 是由於若是消息發送了,可是B沒有收到,這條鏈路就斷了
End transaction
commit;
定時任務讀取A消息表 發送消息
當上述事務提交成功後，咱們經過實時消息服務將此消息通知用戶B，用戶B處理成功後發送回覆成功消息，用戶A收到回覆後修改該條消息數據的狀態。
用戶A收到回覆消息,,把消息從消息表中刪除,並插入到消息備份表中,(可用於消息補償)
防止消息的屢次投遞. 在B端作冪等控制, 在B端記錄消息的消費狀況
B端執行的狀況的時候,都要先去查詢一下這個消息是否存在,若是存在直接放棄.若是不存在就執行B的加錢操做,而後往消息表裏面插入接收到的消息數據.這些操做在一個事務裏面架構
定時任務去檢索消息表,發送消息消費成功回調消息給A
消息與業務解耦
上述保存消息的方式使得消息數據和業務數據緊耦合在一塊兒，從架構上看不夠優雅，並且容易誘發其餘問題。爲了解耦，能夠採用如下方式。併發
1）用戶A在扣款事務提交以前，向實時消息服務請求發送消息，實時消息服務只記錄消息數據，而不真正發送，只有消息發送成功後纔會提交事務；分佈式
2）當用戶A扣款事務被提交成功後，向實時消息服務確認發送。只有在獲得確認發送指令後，實時消息服務才真正發送該消息；高併發
3）當用戶A扣款事務提交失敗回滾後，向實時消息服務取消發送。在獲得取消發送指令後，該消息將不會被髮送；接口
4）對於那些未確認的消息或者取消的消息，須要有一個消息狀態確認系統定時去用戶A系統查詢這個消息的狀態並進行更新。爲何須要這一步驟，
舉個例子：假設在第2步用戶A扣款事務被成功提交後，系統掛了，此時消息狀態並未被更新爲「確認發送」，從而致使消息不能被髮送。事務
優勢：消息數據獨立存儲，下降業務系統與消息系統間的耦合；資源
缺點：一次消息發送須要兩次請求；業務處理服務須要實現消息狀態回查接口。it