前面有一篇關於事物對文章，裡面提到了分布式系統的事物的處理的兩種思想：一種是基於cpa的；一種是基於base。前面只是簡單的說了這兩種思想的概念。這裡來往深入看看這兩種思想，我們有那些可以實施方案。
cpa因為在系統中我們沒法同事滿足這三個條件，所以我們一般利用其中的pc兩個，從一致性和容錯率來入手，犧牲一定的可靠性，從而來達到系統的強一致性。在這個方式下，現在一般有三種煩死。第一種：2pc 兩次提交方案。在這裡我們首先要知道，為了保證（其實也不一定保證的了）分布式系統中每乙個子系統的能夠實現資料的一致性;第二種方案就是，3pc就是三次提交。還有就是tcc方案。
2pc(二次提交)的方案：從字面字面意思理解，就是說要提交兩次，那麼。我們就要想想，如何提交兩次了。而且這兩次是有什麼區別。
首先，我們想想，有這麼乙個分布式的系統，裡面有訂單，積分，倉庫等子系統。那麼，乙個訂單到了訂單系統之後，是不是我們還要到倉庫系統去對庫存進行操作，到積分系統裡面去對客戶的積分進行操作。而且在理想狀態下，我們的每一筆的操作，在訂單，積分，倉庫這三個系統中，是不是都應該要麼都成功，要麼都失敗。
而基礎pc思想，我們要保證系統為了保證資料的強一致性（其實也不能夠百分百保證資料的強一直性）。本來各個系統的事務是單獨不影響彼此的。但是如果我們建立乙個事務管理器來管理每乙個子系統的事務，只有當每乙個子系統的事務都能過成功的時候，我們就統一提交。如果有乙個沒有成功，那麼我們回滾。這樣是不是能夠保證資料庫的資料的一致性。
那麼，第一次預提交；與第二次提交有什麼區別，其實第一次預提交，就是相當於模擬一次事務的提交操作，從而來判斷是否能夠成功。而第二次提交，才是真正的把資料寫入資料庫。那麼，在這其中，我們能夠想想有什麼不足了。
1.如果事務管理器出現故障，就會導致整個流程出錯。
2.操作流程占用資源的時間長。
3.如果問題出現在第二次提交的時候出現故障，也會導致資料的一致性不成立。
針對第乙個問題，人們提出了3pc的概念，其實就是引入時間機制，就是讓每個子系統的事務也有相當於最大連線時間。這樣，就可以避免因為事務管理器的故障，導致各個系統的連線沒有斷開的問題。而3pc就是把2pc的第一次提交的階段給分為了can commit階段：就是去判斷是否能夠進行提交操作；pre commit階段，就是進行預提交階段。但是他還是避免不了資源占用時間久，最後提交的失敗導致的資料不一致的問題。
而tcc 這中方案，在我看來，就在一定程度是，解決了在占用資源時間久，最後一次提交有失敗的風險的問題，但是他也有自己的問題。這個方案就在下個部落格中，與大家說說
Spring學習筆記 二 防Spring事物控制
public class conutils 在threadlocal中獲取連線物件，如果沒有，新建立乙個connection,並賦值到threadlocal中 param return throws sqlexception public connection getthreadconnection...
mysql 筆記 事務
一 問題讀取 1.髒讀 dirty read 事務1更新了某一條記錄，但未提交 事務2讀取到新的未提交記錄 事務1回滾。2.不可重複讀取 nonrepeatable read 不可重複讀，是指在資料庫訪問中，乙個 事務範圍內兩個相同的查詢卻返回了不同資料。例子 事務1讀取某一條記錄 事務2修改事務1...
mysql筆記 事務
寫日誌為什麼比直接寫磁碟要快？使用事務日誌，儲存引擎在修改表的資料時，只需要修改其記憶體拷貝，再把該修改行為記錄到硬碟上的事務日誌中，而不用每次都將修改的資料本身持久到磁碟。事務日誌採用的是追加的方式，因此寫日誌的操作是磁碟上一小塊區域內的順序i o，而不是隨機i o，所以快很多。事務日誌持久以後，...