1 本地事務ACID 和 CAP中的CA區別

    本地事務： A--》 原子性 一個事務中所有操作，要不全部完成，要不全部不完成，事務在執行過程中發生錯誤，會被回滾到事務開始前的狀態，就像這個事務沒有被執行過一樣。

                      C--> 一致性  事務的一致性指在一個事務執行之前和執行之後資料庫都必須處於一致性狀態，如果事務成功完成，那麼系統中所有變化將正確應用。系統處於有效狀態。如果在事務中出現錯誤，系統中所有變化都自動回滾，系統將返回到原始狀態。

                    I--》 隔離性 指的是在併發環境中，當不同的事務同時操作相同的資料時，每個事務都有各自的完成資料空間。打個比方，你買東西，是不會影響到其他人的。

                    D：永續性 指的是隻要事務成功結束，它對資料庫所作的更新就必須永久儲存下來。即使系統發生崩潰，重新啟動資料庫系統後，資料庫還能恢復到事務成功結束時的狀態

                   打個比方，買東西的時候需要記錄在賬本上，即使老闆忘記了  也有據可查

分散式事務

     CAP定理 

            C -->一致性   對某個指定的客戶端來說，讀操作能返回最新的寫操作，資料分佈在不同節點上的資料來說，如果在某個節點更新了資料，那麼在其他節點如果都能讀取到這個最新的資料，那麼就稱為強一致，如果在某個節點沒有讀取到，就是分散式不一致。

         A --> 可用性 非故障的節點在合理的時間內返回合理的響應（不是錯誤和超時的響應。）可用性的兩個關鍵是一個合理的時間，一個合理的響應。

合理的時間指的是請求不能無限被阻塞，應該在合理的時間給出返回。合理的響應指的是系統應該明確返回結果並且結果是正確的。

2.分散式事務常用的解決方案的優缺點是什麼？ 適用於什麼場景？

解決方案：

1.XA Transactions

2.TCC

3. 本地訊息表

4.MQ事務

5.Saga事務

TODO   --- 完整優缺點及使用場景

缺點： 增加系統的複雜度和成本

3.分散式事務出現的原因？ 用來解決什麼痛點？

分散式事務出現的兩種原因：

Service產生多個節點 

     舉個例子：  一個公司之內，使用者的資產可能分為好多個部分，分為餘額，積分，優惠券等等

，在公司內部有可能積分功能由一個微服務團隊維護，優惠券又是另外的團隊維護。這樣就無法保證積分扣減之後，優惠券能否扣減成功。

Resource產生多個節點

   Mysql一般裝千萬級的資料就得進行分庫分表

   對於一個支付寶的轉賬業務來說，你給朋友轉錢，可能你的資料庫在北京，而你朋友的錢存在上海，所以依然無法保證他們能同時成功

用來保證不同資料庫的資料一致性