分佈式事務是什麼？三要素是什麼？
cap是啥
CAP是Consistency、Availability、Partitiontolerance三個詞語的縮寫，分別表示一致性、可用性、分區容忍性。
原有一顆樹苗價格爲30元，植樹節到了，改價一顆樹苗爲28元，在改的時候，正在改，對主庫數據進行修改，而在買家查看時是從從庫讀的，這時，還沒有修改完，還是30元。
一致性C-Consistency：
樹苗改價格的時候，要將從數據庫鎖定通過，不讓讀，改完，同步給從數據庫，再讀，這就是一致性。
可用性：A-Availability：
如果要保證絕對的一致性，那麼就可能出現網絡超時或者響應錯誤
如果要保證可用，即使數據不一致，無所謂，那麼就不能保證可用性，發現兩者剛好相反
所以出現了基於P的AP CP
後面說
分區容錯性：P-Partition tolerance：
通常分佈式系統的各各結點部署在不同的子網，這就是網絡分區，不可避免的會出現由於網絡問題而導致結點之間通信失敗，此時仍可對外提供服務，這叫分區容忍性。
例如：第三方物流系統和商城平臺系統，可能就是兩撥人，360商城相對較大的業務還是用的第三方物流
1、儘量使用異步取代同步操作，例如使用異步方式將數據從主數據庫同步到從數據，這樣結點之間能有效的實現松耦合。2、添加從數據庫結點，其中一個從結點掛掉其它從結點提供服務。
集羣，主從，哨兵，實際上就是爲了保證分區容錯，不至於沒有替代，直接系統癱瘓
1）AP：放棄一致性，追求分區容忍性和可用性。這是很多分佈式系統設計時的選擇。
通常實現AP都會保證最終一致性，後面講的BASE理論就是根據AP來擴展的，一些業務場景比如：訂單退款，今日退款成功，明日賬戶到賬，只要用戶可以接受在一定時間內到賬即可。
2）CP：放棄可用性，追求一致性和分區容錯性，我們的zookeeper其實就是追求的強一致，又比如跨行轉賬，一次轉賬請求要等待雙方銀行系統都完成整個事務纔算完成。
BASE理論
base理論實際上就是滿足可用性，對於一致性來說，保證最終一致性。
BASE是BasicallyAvailable(基本可用)、Softstate(軟狀態)和Eventuallyconsistent(最終一致性)三個短語的縮寫。
BASE理論是對CAP中AP的一個擴展，通過犧牲強一致性來獲得可用性，當出現故障允許部分不可用但要保證核心功能可用，允許數據在一段時間內是不一致的，但最終達到一致狀態。滿足BASE理論的事務，我們稱之爲“柔性事務”。
基本可用:分佈式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。如，電商網站交易付款出現問題了，商品依然可以正常瀏覽。
軟狀態:由於不要求強一致性，所以BASE允許系統中存在中間狀態（也叫軟狀態），這個狀態不影響系統可用性，如訂單的"支付中"、“數據同步中”等狀態，待數據最終一致後狀態改爲“成功”狀態。
最終一致:最終一致是指經過一段時間後，所有節點數據都將會達到一致。如訂單的"支付中"狀態，最終會變爲“支付成功”或者"支付失敗"，使訂單狀態與實際交易結果達成一致，但需要一定時間的延遲、等待。
分佈式事務解決方案：2PC
分兩階段提交
https://my.oschina.net/architectliuyuanyuan/blog/4968459
在我的博客裏面沒已經提過
張三和李四好久不見，老友約起聚餐，飯店老闆要求先買單，才能出票。這時張三和李四分別抱怨近況不如意，囊中羞澀，都不願意請客，這時只能AA。只有張三和李四都付款，老闆才能出票安排就餐。但由於張三和李四都是鐵公雞，形成了尷尬的一幕：
準備階段：老闆要求張三付款，張三付款。老闆要求李四付款，李四付款。提交階段：老闆出票，兩人拿票紛紛落座就餐。例子中形成了一個事務，若張三或李四其中一人拒絕付款，或錢不夠，店老闆都不會給出票，並且會把已收款退回。整個事務過程由事務管理器和參與者組成，店老闆就是事務管理器，張三、李四就是事務參與者，事務管理器負責決策整個分佈式事務的提交和回滾，事務參與者負責自己本地事務的提交和回滾。
在計算機中部分關係數據庫如Oracle、MySQL支持兩階段提交協議，
1.準備階段（Preparephase）：事務管理器給每個參與者發送Prepare消息，每個數據庫參與者在本地執行事務，並寫本地的Undo/Redo日誌，此時事務沒有提交。（Undo日誌是記錄修改前的數據，用於數據庫回滾，Redo日誌是記錄修改後的數據，用於提交事務後寫入數據文件）
2.提交階段（commitphase）：如果事務管理器收到了參與者的執行失敗或者超時消息時，直接給每個參與者發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據事務管理器的指令執行提交或者回滾操作，並釋放事務處理過程中使用的鎖資源。注意:必須在最後階段釋放鎖資源。
分佈式事務處理模型DTP（DistributedTransactionProcessingReferenceModel）。
這個很重要的
DTP模型定義如下角色：
AP(ApplicationProgram)：即應用程序，可以理解爲使用DTP分佈式事務的程序。
RM(ResourceManager)：即資源管理器，可以理解爲事務的參與者，一般情況下是指一個數據庫實例，通過資源管理器對該數據庫進行控制，資源管理器控制着分支事務。
TM(TransactionManager)：事務管理器，負責協調和管理事務，事務管理器控制着全局事務，管理事務生命週期，並協調各個RM。全局事務是指分佈式事務處理環境中，需要操作多個數據庫共同完成一個工作，這個工作即是一個全局事務。
tm會分配一個全局事務id gtx_id global_transaction_manager_id,
rm resource manager 類似於本地事務
多個本地事務組成了分佈式事務。
DTP模型定義TM和RM之間通訊的接口規範叫XA，簡單理解爲數據庫提供的2PC接口協議，基於數據庫的XA協議來實現2PC又稱爲XA方案。
以上三個角色之間的交互方式如下：
1）TM向AP提供應用程序編程接口，AP通過TM提交及回滾事務。
2）TM交易中間件通過XA接口來通知RM數據庫事務的開始、結束以及提交、回滾等。
總結：整個2PC的事務流程涉及到三個角色AP、RM、TM。AP指的是使用2PC分佈式事務的應用程序；RM指的是資源管理器，它控制着分支事務；TM指的是事務管理器，它控制着整個全局事務。
1）在準備階段RM執行實際的業務操作，但不提交事務，資源鎖定；
2）在提交階段TM會接受RM在準備階段的執行回覆，只要有任一個RM執行失敗，TM會通知所有RM執行回滾操作，否則，TM將會通知所有RM提交該事務。提交階段結束資源鎖釋放。
XA方案的問題：
1、需要本地數據庫支持XA協議。
2、資源鎖需要等到兩個階段結束才釋放，性能較差。
seata hmily
tcc 是啥，
DTP模型 ---> XA協議
ap rm rm
有哪三種情況可能會產生分佈式事務