分布式系統下，分布式數據庫遇到的挑戰
分布式系統下，當訪問關系型數據庫的i/o占用過高，內存不足，訪問過慢的情況下，可以考慮流流行的分庫分表的策略，但是這樣也會到來很多新的技術挑戰。
1.分布式事務
當還是單體應用，單體數據庫時，完全不需要考慮事務的一致性問題，因為mysql已經幫我們處理事務問題(ACID)，但是這只是針對單體情況下，如果是多個數據庫，主從備份，讀寫分離，那么就會可能造成事務不一致的情況，那么什么事分布式事務，分布式
事務又該如何解決呢？
1.有關於事務的概念
本地事務：本地事務的優點就是支持嚴格的ACID特性，高效，可靠，狀態可以只在資源管理器中維護，而且應用編程模型簡單。
全局事務：當事務由全局事務管理器進行全局管理時成為全局事務，事務管理器負責管理全局的事務狀態和參與的資源，協同資源的一致提交回滾。
兩階段事務：兩階段事務提交采用的是X/OPEN組織所定義的DTP模型，通過抽象出來的AP, TM, RM的概念可以保證事務的強一致性。 其中TM和RM間采用XA的協議進行雙向通信。 與傳統的本地事務相比，
XA事務增加了prepare階段，數據庫除了被動接受提交指令外，還可以反向通知調用方事務是否可以被提交。 因此TM可以收集所有分支事務的prepare結果，最后進行原子的提交，保證事務的強一致性。
BASE理論：BA指的是基本業務可用性，支持分區失敗，S表示柔性狀態，也就是允許短時間內不同步，E表示最終一致性，數據最終是一致的，但是實時是不一致的。原子性和持久性必須從根本上保障，為了可用性、性能和服務降級的需要，只有降低一致性和隔離性的要求。
CAP定理：對於共享數據系統，最多只能同時擁有CAP其中的兩個，任意兩個都有其適應的場景，真是的業務系統中通常是ACID與CAP的混合體。分布式系統中最重要的是滿足業務需求，而不是追求高度抽象，絕對的系統特性。C表示一致性，也就是所有用戶看到的數據是一樣的。
A表示可用性，是指總能找到一個可用的數據副本。P表示分區容錯性，能夠容忍網絡中斷等故障。
2.解決方案
1.兩階段（2PC）解決方案
兩階段提交其實比較簡單，這邊有兩個資源提供准備和提交兩個接口。
由於隔離性互斥的要求，在事務執行過程中，所有的資源都是被鎖定的，這種情況只適合執行時間確定的短事務。 但是為了保證分布式事務的一致性，大都是采用串行化的隔離級別來保證事務一致性，這樣會降低系統的吞吐。
但因為2PC的協議成本比較高，又有全局鎖的問題，性能會比較差。 現在大家基本上不會采用這種強一致解決方案。
2.TCC事務補償方案
TCC名字的由來是其中包含了 try, confirm, cancel三個操作。
與兩階段提交相比，TCC位於業務服務層， 沒有單獨的准備階段，Try操作可以靈活選擇業務資源鎖的粒度。TCC是通過最終一致性來解決系統性能問題的這個設計，對我們設計抉擇有很大的啟發。 有些時候系統的技術問題是可以通過業務建模的方式來解決的。
3.Saga事務
Saga這個概念來源於三十多年前的一篇數據庫論文Sagas ，一個Saga事務是一個有多個短時事務組成的長時的事務。 在分布式事務場景下，我們把一個Saga分布式事務看做是一個由多個本地事務組成的事務，每個本地事務都有一個與之對應的補償事務。
在Saga事務的執行過程中，如果某一步執行出現異常，Saga事務會被終止，同時會調用對應的補償事務完成相關的恢復操作，這樣保證Saga相關的本地事務要么都是執行成功，要么通過補償恢復成為事務執行之前的狀態。
Saga定義了一個事務中的每個子事務都有一個與之對應的反向補償操作。由Saga事務管理器根據程序執行結果生成一張有向無環圖，並在需要執行回滾操作時，根據該圖依次按照相反的順序調用反向補償操作。Saga事務管理器只用於控制何時重試，何時補償，
並不負責補償的內容，補償的具體操作需要由開發者自行提供。
SAGA可以看做一個異步的、利用隊列實現的補償事務。
其適用於無需馬上返回業務發起方最終狀態的場景，例如：你的請求已提交，請稍后查詢或留意通知 之類。
將上述補償事務的場景用SAGA改寫，其流程如下：
-
-
- 訂單服務創建最終狀態未知的訂單記錄，並提交事務
- 現金服務扣除所需的金額，並提交事務
- 訂單服務更新訂單狀態為成功，並提交事務
-
以上為成功的流程，若現金服務扣除金額失敗，那么，最后一步訂單服務將會更新訂單狀態為失敗。
其業務編碼工作量比補償事務多一點，包括以下內容：
-
-
- 訂單服務創建初始訂單的邏輯
- 訂單服務確認訂單成功的邏輯
- 訂單服務確認訂單失敗的邏輯
- 現金服務扣除現金的邏輯
- 現金服務補償返回現金的邏輯
-
但其相對於補償事務形態有性能上的優勢，所有的本地子事務執行過程中，都無需等待其調用的子事務執行，減少了加鎖的時間，這在事務流程較多較長的業務中性能優勢更為明顯。同時，其利用隊列進行進行通訊，具有削峰填谷的作用。
因此該形式適用於不需要同步返回發起方執行最終結果、可以進行補償、對性能要求較高、不介意額外編碼的業務場景。
但當然SAGA也可以進行稍微改造，變成與TCC類似、可以進行資源預留的形態。
4.基於消息事務
基於消息實現的事務適用於分布式事務的提交或回滾只取決於事務發起方的業務需求，其他數據源的數據變更跟隨發起方進行的業務場景。
舉個例子，假設存在業務規則：某筆訂單成功后，為用戶加一定的積分。
在這條規則里，管理訂單數據源的服務為事務發起方，管理積分數據源的服務為事務跟隨者。
從這個過程可以看到，基於消息隊列實現的事務存在以下操作：
-
-
- 訂單服務創建訂單，提交本地事務
- 訂單服務發布一條消息
- 積分服務收到消息后加積分
-
我們可以看到它的整體流程是比較簡單的，同時業務開發工作量也不大：
-
-
- 編寫訂單服務里訂單創建的邏輯
- 編寫積分服務里增加積分的邏輯
-
可以看到該事務形態過程簡單，性能消耗小，發起方與跟隨方之間的流量峰谷可以使用隊列填平，同時業務開發工作量也基本與單機事務沒有差別，都不需要編寫反向的業務邏輯過程。因此基於消息隊列實現的事務是我們除了單機事務外最優先考慮使用的形態。