base理論
分布式事務解決方案
3pc模式
柔性事務-tcc 事務補償型方案
柔性事務- 最大努力通知型方案
柔性事務- 可靠訊息+最終一致性方案（非同步確保型）參考
cap原則即為 以上三要素只能同時實現兩點，不能三者兼顧，對於多數大型網際網路的應用場景，主機眾多，部署分散，而現在的集群規模越來越大，所以節點故障、網路故障是常態，而且要保證服務可用性達到99.99…% 即保證ap，捨棄c永遠要滿足分割槽容錯
每個分割槽都會產生乙個領導，最後根據選舉代數高的作為最新領導。如果每個分割槽節點數量相同，選不出領導，直接響應客戶端集群當前不可用
軟狀態（soft state） 指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分布式儲存中一般乙份資料有多個副本，允許不同副本同步的延時就是 軟狀態的體現。mysql replication的非同步複製也是一種體現
最終一致性（eventual consistency） 指系統中的所有資料副本經過一定時間後，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況
資料庫支援的2pc【2 phase commit 二階提交】，又叫做 xa transaction mysql從5.5版本開始支援，sql server 2005開始支援，oracle7開始支援 xa是乙個兩階段提交協議，該協議分為以下兩個階段：
2pc 是乙個同步阻塞協議，第一階段協調者會等待所有參與者響應才會進行下一步操作，第一階段的協調者有超時機制，假設因為網路原因沒有收到某參與者的響應或某參與者掛了，那麼超時後就會判斷事務失敗，向所有參與者傳送回滾命令。
第二階段協調者的沒有超時機制，只能不斷重試！
每個參與者自身的狀態只有自己和協調者知道，所以當老協調者和某些參與者一起掛掉之後，新協調者不知道這些掛掉的參與者之前的狀態，也無法繼續做決定，可能會出現資料不一致的情況。
特點：3pc 包含了三個階段，分別是準備階段、預提交階段和提交階段：cancommit、precommit 和 docommit。
3pc準備階段=了解參與者執行狀況，是否可以參加事務，而不會直接執行事務
3pc預提交=2pc準備階段
3pc提交=2pc提交
引入了超時機制，參與者就不會傻等了，如果是等待提交命令超時，那麼參與者就會提交事務了，因為都到了這一階段了大概率是提交的，如果是等待預提交命令超時，那該幹啥就幹啥了，反正本來啥也沒乾。
然而超時機制也會帶來資料不一致的問題，比如在等待提交命令時候超時了，參與者預設執行的是提交事務操作，但是有可能執行的是回滾操作，這樣一來資料就不一致了。
tcc 是業務層面的分布式事務
tcc 指的是try - confirm - cancel。
一階段：prepare行為，呼叫自定義的prepare邏輯
二階段：commit行為，呼叫自定義的commit邏輯
三階段：rollback行為，呼叫自定義的rollback邏輯 tcc支援把自定義的分支事務納入全域性事務的管理中
tcc 對業務的侵入較大和業務緊耦合，撤銷和確認操作的執行可能需要重試，因此還需要保證操作的冪等。
業務處理服務在業務事務提交之前，向實時訊息服務請求傳送訊息，實時訊息服務只記錄訊息資料，而不是真正地傳送。業務處理服務在業務事務提交之後，向實時訊息服務確認傳送，只有在得到確認傳送指令後，實時訊息服務才會真正傳送
分布式事務
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...
分布式之分布式事務
被人問到分布式事務，之前學rabbitmq 的時候學到過rabbitmq 高階的事務，因為沒有用過，所有沒有回答好。這裡總結一下。1.單機版事務。事務的四大特性 acid a.原子性 b.一致性 c.隔離性 d.永續性 單機事務可以通過設定事務的隔離級別 參見spring 的事務隔離級別 2.分布式...