通過這兩天對于分布式事務的學習，結合網上的資料，感覺這部分的知識在博客中全都大同小異，無非就是兩階段提交（2PC）、補償事務（TCC）、MQ 事務消息這三種模式，并沒有一種是很完美解決這個問題的，也沒有一個對應的規范來告訴我們，分布式事務究竟要如何完美的處理。通過繼續的查找資料能夠看出來，這種規范和方式不是沒有，而是每個大公司都有一套自己的方案來實現，并且不對外公開。但我感覺不論如何變化，如何實現，都是基于業務的，有些業務可以放棄可用性但要保證絕對的數據一致，但有些業務可以容忍數據的少量不一致，但要保證性能。總之既然暫時找不到也接觸不到好的方法，就先從上述三種方式來理解，變化的話也不會變化太大。
集群和分布式的區別
對比之前Weblogic服務器集群的配置，通俗易懂的說：一個業務拆分成多個子業務，部署在不同的服務器上，是分布式。同一個業務，部署在多個服務器上，是集群。也就是說集群是解決高可用的，而分布式是解決高性能、高并發的。
CAP定理
首先是CAP原則，又稱CAP定理，指的是在一個分布式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
- 一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同于所有節點訪問同一份最新的數據副本）
- 可用性（A）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
- 分區容錯性（P）：以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。
BASE理論
在分布式系統中，我們往往追求的是可用性，它的重要程序比一致性要高，那么如何實現高可用性呢？BASE理論就是為了解決關系數據庫強一致性引起的問題而引起的可用性降低而提出的解決方案。
- Basically Available（基本可用）
- Soft state（軟狀態）
- Eventually consistent（最終一致性）
BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）。
兩階段提交（2PC）
二階段提交（Two-phase Commit）是指，為了使基于分布式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種算法。通常，二階段提交也被稱為是一種協議(Protocol)。在分布式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的組件來統一掌控所有節點(稱作參與者)的操作結果并最終指示這些節點是否要把操作結果進行真正的提交(比如將更新后的數據寫入磁盤等等)。因此，二階段提交的算法思路可以概括為： 參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。
二階段提交算法的成立基于以下假設：
- 該分布式系統中，存在一個節點作為協調者(Coordinator)，其他節點作為參與者(Cohorts)。且節點之間可以進行網絡通信。
- 所有節點都采用預寫式日志，且日志被寫入后即被保持在可靠的存儲設備上，即使節點損壞不會導致日志數據的消失。
- 所有節點不會永久性損壞，即使損壞后仍然可以恢復。
基本算法
第一階段（提交請求階段）
- 協調者節點向所有參與者節點詢問是否可以執行提交操作，并開始等待各參與者節點的響應。
- 參與者節點執行詢問發起為止的所有事務操作，并將Undo信息和Redo信息寫入日志。
- 各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個"同意"消息；如果參與者節點的事務操作實際執行失敗，則它返回一個"中止"消息。
有時候，第一階段也被稱作投票階段，即各參與者投票是否要繼續接下來的提交操作。
第二階段（提交執行階段）
【成功】當協調者節點從所有參與者節點獲得的相應消息都為"同意"時：
- 協調者節點向所有參與者節點發出"正式提交"的請求。
- 參與者節點正式完成操作，并釋放在整個事務期間內占用的資源。
- 參與者節點向協調者節點發送"完成"消息。
- 協調者節點收到所有參與者節點反饋的"完成"消息后，完成事務。
【失敗】如果任一參與者節點在第一階段返回的響應消息為"終止"，或者 協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應消息時：
- 協調者節點向所有參與者節點發出"回滾操作"的請求。
- 參與者節點利用之前寫入的Undo信息執行回滾，并釋放在整個事務期間內占用的資源。
- 參與者節點向協調者節點發送"回滾完成"消息。
- 協調者節點收到所有參與者節點反饋的"回滾完成"消息后，取消事務。
缺點
二階段提交算法的最大缺點就在于它的執行過程中間，節點都處于阻塞狀態。即節點之間在等待對方的相應消息時，它將什么也做不了。特別是，當一個節點在已經占有了某項資源的情況下，為了等待其他節點的響應消息而陷入阻塞狀態時，當第三個節點嘗試訪問該節點占有的資源時，這個節點也將連帶陷入阻塞狀態。
另外，協調者節點指示參與者節點進行提交等操作時，如有參與者節點出現了崩潰等情況而導致協調者始終無法獲取所有參與者的響應信息，這時協調者將只能依賴協調者自身的超時機制來生效。但往往超時機制生效時，協調者都會指示參與者進行回滾操作。這樣的策略顯得比較保守。
三階段提交（3PC）
...
補償事務（TCC）
...
MQ 事務消息
... 增加近日對 ActiveMQ 的學習總結
這些還都只是大致的了解，感覺也不是什么好的解決辦法，之后會查一查谷歌，看看有沒有什么好的方法，或對于上面的三種方法好的講解。
最近在某篇文章上看到分布式事務的唯一一種解決方案便是Paxos算法，上述的所有方法都是Paxos算法的不完整版，而這個算法極其難以理解，Zookeeper的出現，就是為了簡化這些難以理解的操作。
下一周決定將上面的算法補全，其中事務消息模式增加最近對MQ的學習，整理Paxos算法以及Zookeeper對于分布式事務的具體作用。
總的來看，分布式事務并不是不能實現，只不過需要借助Zookeeper來實現。
