1. TXC是什麼
TXC(Taobao Transaction Constructor)是阿里巴巴的一個分佈式事務中間件，它可以通過極少的代碼侵入，實現分佈式事務。
在大部分情況下，應用只需要引入TXC Client的jar包，進行幾項簡單配置，以及以行計的代碼改造，即可輕鬆保證分佈式數據一致性。
TXC同時提供了豐富的編程和配置策略，以適應各種長尾的應用需求。
一個數據庫事務通常包含了一個序列的對數據庫的讀/寫操作。它的存在包含有以下兩個目的：
爲數據庫操作序列提供了一個從失敗中恢復到正常狀態的方法，同時提供了數據庫即使在異常狀態下仍能保持一致性的方法。
當多個應用程序在併發訪問數據庫時，可以在這些應用程序之間提供一個隔離方法，以防止彼此的操作互相干擾。並非任意的對數據庫的操作序列都是數據庫事務。數據庫事務擁有以下四個特性，習慣上被稱之爲 ACID特性。
- 原子性（Atomicity）：事務作爲一個整體被執行，包含在其中的對數據庫的操作要麼全部被執行，要麼都不執行。
- 一致性（Consistency）：事務應確保數據庫的狀態從一個一致狀態轉變爲另一個一致狀態。一致狀態的含義是數據庫中的數據應滿足完整性約束。
- 隔離性（Isolation）：多個事務併發執行時，一個事務的執行不應影響其他事務的執行。
- 持久性（Durability）：已被提交的事務對數據庫的修改應該永久保存在數據庫中。
分佈式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的 分佈式系統 的不同節點之上。
在應用程序只部署在一臺計算機，數據庫只部署在一臺計算機的情況下，事務的ACID四個特性很容易全部滿足。
但是單機的處理能力很容易達到上限，此時必須使用分佈式系統。在分佈式環境下，應用程序可能部署在多臺計算機，並且可能有多個不同的應用程序參與到同一個事務中；數據庫也可能部署在多臺計算機，並且多個不同的數據庫可能會參與到同一個事務中。在這樣的分佈式環境下，高吞吐量和ACID很難被同時滿足。
兩階段提交，是實現分佈式事務的成熟方案。第一階段是表決階段，是所有參與者都將本事務能否成功的反饋發給協調者；第二階段是執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提交，或者在所有分支上回滾。
兩階段提交可以滿足ACID，但代價是吞吐量。例如，數據庫需要頻繁地對資源上鎖等等。而且更致命的是，資源被鎖住的時間相對較長----在第一階段即需要上鎖，第二階段才能解鎖，依賴於所有分支的最慢者----這期間沒有任何人可以對該資源進行修改。
兩階段提交理論的一個廣泛工業應用是XA協議。目前幾乎所有收費的商業數據庫都支持XA協議。XA協議已在業界成熟運行數十年，但目前它在互聯網海量流量的應用場景中，吞吐量這個瓶頸變得十分致命，因此很少被用到。
TCC（Try、Confirm、Cancel）是兩階段提交的一個變種。TCC提供了一個框架，需要應用程序按照該框架編程，將業務邏輯的每個分支都分爲Try、Confirm、Cancel三個操作集。TCC讓應用程序自己定義數據庫操作的粒度，使得降低鎖衝突、提高吞吐量成爲可能。
以一個典型的淘寶訂單爲例，按照TCC框架，應用需要在Try階段將商品的庫存減去，將買家支付寶賬戶中的相應金額扣掉，在臨時表中記錄下商品的數量，訂單的金額等信息；另外再編寫Confirm的邏輯，即在臨時表中刪除相關記錄，生成訂單，告知CRM、物流等系統，等等；以及Cancel邏輯，即恢復庫存和買家賬戶金額，刪除臨時表相關記錄。
我們能找到的最早出處是atomikos的ExtremeTransactions產品中提出了TCC的概念。在撰寫本文時，atomikos網站不能訪問，只能在百度百科裏面找到一篇 相關的文章。目前，TCC概念最大的應用，一般認爲是支付寶XTS系統。
最終一致性目前沒有公認的定義。一般來說，它是指事務進行中，某些分支的中間狀態可以被事務外觀察到，即"讀未提交"，從而導致多個分支的狀態可能不一致，但所有分支 最終 會達到要麼全部提交，要麼全部回滾的一致狀態。
很明顯，最終一致性部分犧牲了ACID中的C和I，但它帶來了可觀的收益：資源不再需要長時間上鎖，極大地提高了吞吐量。
最終一致性在互聯網應用場景中被廣泛用做吞吐量和ACID的妥協點。
讓我們回到前面TCC的例子。在這個流程中，商品庫存和買家餘額都沒有被鎖住，因此可以得到很高的吞吐量。但在交易進行中，商品庫存和買家餘額的變化就已經被外界感知到，而物流系統卻可能還沒有相應的記錄，此時數據是不一致的，但最終（無論是Confirm階段結束後，還是Cancel階段結束後）它們會一致。
TXC的目標應用場景是：解決在分佈式應用中，多條數據庫記錄被修改而可能帶來的一致性問題；該分佈式應用可以接受最終一致性；該應用的事務改造對工作量有較嚴格的限制。
如前所述，目前業內的所有分佈式事務中間件都很難在保持高吞吐量的前提下，完全滿足ACID四個特性。目前幾乎所有的分佈式事務中間件都是以犧牲這5個指標（性能、ACID）中的一個或多個來實現事務的，它們的區別往往在於犧牲了不同的指標。例如兩階段提交就是犧牲了性能，而ExtremeTransactions和XTS則是犧牲了一致性和隔離性。
在這方面，TXC也採用了最終一致性，因此部分犧牲了一致性和隔離性。在此前提下，TXC在性能、隔離性之間提供了數個平衡點，應用程序管理員可以通過配置不同的TXC策略來選擇本應用所需要的平衡點。詳情請見後續章節。
除了數據一致性之外，爲了實現分佈式事務而花在開發上的開銷，也是一個值得考慮的因素。如果沒有分佈式事務中間件，要達到類似目的，需要爲業務上的每一個寫SQL都編寫回滾操作，這些回滾操作還必須是冪等的，應用程序員還要決定什麼時候調用這些回滾操作中的全部或一部分----毫無疑問這些工作是繁瑣而容易出錯的。
所有的中間件，其目的都是爲了讓業務只需要關注於業務。通過TXC的自動接口，應用程序員只需要指定事務的邊界，即可實現分佈式事務，代碼修改可以短至1行。代碼侵入少了，犯錯誤的概率就小，開發週期也會隨之縮短。
最後，和支付寶XTS類似，TXC也提供了靈活、強大的類似TCC的手動接口，以較多的代碼修改獲取較高的性能。
TXC推薦應用程序以自動接口實現大部分邏輯，用手動接口實現對性能非常敏感的一小部分核心邏輯。TXC保證這些邏輯都可以被包含在在同一個分佈式事務中。
TXC的事務可以在應用之間隨着HSF服務調用被傳播，使得跨多應用、跨多庫的數據庫操作可以被包含在同一個事務內。這些不同的應用可以採用不同的TXC配置，從而滿足各種各樣的應用需求。
綜上所述，TXC的目標場景，是最終一致性、開發簡便快捷、跨多應用的事務場景。
事務超時時間 – TXC中，對每個分佈式事務均需設定一個超時時間，超出超時時間未被提交的事務，均會被TXC框架回滾。
事務分支 – 一個分佈式事務可能包含多個分支，只有當所有的分支全部成功時，分佈式事務才能成功，一個分支的失敗將導致分佈式事務的回滾。在TXC框架下，分支可能是一個分庫上執行的sql語句，或是一個手動模式分支。
事務邊界 – 分佈式事務需要進行開啓，在執行結束後需要進行結束（提交或回滾），事務開啓和關閉即劃定了一個事務邊界。
事務模式 – TXC提供的預先定義好的事務模式，不同的事務模式提供了不同的易用性和性能，不同的事務模式組合（詳見最佳實踐）可解決極度複雜的場景。
TXC Client – 事務發起者，用以界定分佈式事務邊界
RM – Resource Manager , Rm是事務中的資源管理器抽象，Rm定義了資源參與到事務中的行爲，不同事務模式對應不同的資源管理器。
TM – Transaction Manager ,泛指事務協調器，在TXC中，其責任由TXC Server承擔。
TXC標準模式（Automatic TXC）是最主要的事務模式，通過基於TDDL的TXC數據源，它對SQL語句提供了分佈式事務支持。它幫助應用方以最小的改造代價來實現TDDL下的事務的功能。
在標準模式下，當開啓了TXC分佈式事務時，TXC框架將自動的根據執行的SQL語句，進行事務分支劃分（每個物理庫上的一個本地事務作爲一個分佈式事務分支），把各個分支統一納入事務。
分佈式事務的隔離級別可以配置，讀未提交（read uncommitted）和讀已提交（read committed）。讀未提交是缺省設置。
標準模式適合於TDDL分庫分表、多TDDL數據源、跨進程的多TDDL數據源等幾乎任何TDDL應用場景下的分佈式事務。
MT（Manual TXC）模式，提供用戶可以介入兩階段提交過程的一種模式。在這種模式下，用戶可以根據自身業務需求自定義在TXC的兩階段中每個階段的具體行爲。MT模式提供了更多的靈活性，可能性，以達到特殊場景下的自定義優化，及特殊功能的實現。
MT模式不依賴於TDDL，這是它相對於標準模式的一個最大的優勢。MT模式幾乎滿足任何我們想到的事務場景。
RT（Retry TXC）模式嚴格地說，不屬於傳統的事務範圍。在TXC將其定義爲一種特殊的事務，它通過在用戶指定時間內不停的異步重試失敗的SQL語句，來保證SQL語句最終成功。
當我們通過TDDL執行一個需要分庫的SQL，假設在第一個庫執行成功了，但是在第二個庫執行失敗了。如果採用TXC標準模式，第一個庫的SQL會回滾。對用戶來說，他的SQL失敗了，在兩個庫上是一致的。
如果採用RT模式，第二個庫執行失敗的SQL會保存下來，TXC不斷重試這個SQL，直到成功。對用戶來說， 他的SQL成功了，在兩個庫上最終是一致的。當然，TXC不會一直重試SQL，用戶可以指定一個超時時間，超過這個時間限制，TXC會發送告警信息到用戶。用戶拿到告警信息後，可以從業務庫的RT SQL表中拿到對應的SQL語句，決定下一步怎麼處理。
試想一下，當一個SQL涉及到分庫，我們執行這個SQL失敗了，通常來說，我們需要通過log查出它在哪幾個庫成功了哪幾個庫失敗了，並且在失敗的庫上不斷重試。這是很繁瑣的。RT模式把用戶從這種繁瑣工作中解脫出來，用戶不再需要關注哪些庫上SQL失敗了，也不需要自己重試SQL。
在AT方式下，事務範圍內所有分支的寫SQL操作應該要麼都執行，要麼都不執行。
在弱隔離性策略下，有微小的可能無法保證一致性，參考"弱隔離性策略"。
所有分支的狀態都會被持久化，整個全局事務的狀態也需要被持久化，以便在TXC Server或者client出故障之後可以回滾事務。
TXC提供了豐富的配置策略，其中與隔離性有關的有3種：弱隔離性策略、強隔離性策略，和重試策略。下面對這3種策略一一進行介紹。
基於追求高吞吐量的考慮，TXC的缺省策略是弱隔離性，即讀未提交。在應用程序尚未執行txc_commit()之前，各個分支上寫操作的結果已經可以被外界觀察到，並且可以被併發地修改。
當事務需要被回滾時，TXC會以反向補償機制來讓事務各個參與者保持數據的一致性。但如果事務中被修改的某條記錄如果在回滾前就被別的事務併發修改了，回滾就無法進行。此時TXC系統將產生報警，需要管理員手工訂正數據。我們稱這個問題爲" 髒寫"。因此，如果應用的業務邏輯決定了不太可能對同一行記錄進行併發修改，缺省模式就比較適合這樣的應用；否則，如果預期對同一行記錄的修改可能會相對頻繁，則推薦使用強隔離性策略。
TXC的強隔離性策略可以防前面提到的髒寫問題，避免手工訂正。
在TXC的強隔離性策略下，所有的寫操作都會檢測目標記錄是否已經被某個進行中的事務修改爲中間狀態。如果是，則寫操作會在一段時間內重試以讀取一個最終狀態，或者在這段時間過去之後返回失敗。同樣的行爲也適用於select for update。
值得突出的是，如果應用A發起一個事務，在它進行中，同一個事務的其他分支（即隨着HSF傳播出去的事務分支）也可以併發地修改同一條記錄，從而實現了緊耦合的事務。目前該功能僅在支持XA的商業解決方案中才被支持。
對於純讀操作，爲了吞吐量考慮，TXC一般不去做類似檢測。當事務進行中對某個記錄進行修改時，該中間狀態可能會被其他事務讀到。我們稱這個問題爲" 髒讀"。一般來說，這樣的髒讀不會有嚴重後果；但如果應用確實需要避免髒讀，那麼可以在select語句上加上一些特定的hint。對於帶這些hint的select語句，TXC也會犧牲性能，先做檢測，如果相關記錄屬於某個事務的中間狀態，select會在一段時間內重試以讀取一個最終狀態，或者在這段時間過去之後返回失敗。
強隔離性策略要求所有可能訪問業務表的應用都部署TXC並配置強隔離性策略。
對於未部署TXC的系統，它們可以在事務進行中，跳過TXC直接併發修改業務表的同一條記錄，從而造成髒寫。目前尚無手段避免這樣的髒寫。
重試策略並不屬於嚴格意義上的事務範疇，因爲需要重試的操作即使失敗，也不會導致事務回滾。
讓我們考察這樣的例子：當一個用戶註銷的時候，需要將該用戶在多個表中的相關記錄刪除。這樣的操作即使一時會因爲網絡、數據庫主庫當機等原因失敗，它最終也基本上能保證會成功，因此業務往往不希望這樣的操作會引起整個事務的回滾，而是希望簡單地重試該操作，直到成功。
在重試策略下，TXC可以"記住"這樣的操作，在適當的時候代替應用執行重試。此時，可能會在比較大的時間窗口內，原子性和一致性沒有被滿足。應用程序需要根據自己的情況，決定是否採用重試策略。
通過一些簡單的配置，TXC事務即可隨HSF服務傳播。即，當應用A發起了一個事務，在事務進行中調用應用B的服務BS1時，如果配置得當，BS1中的所有寫SQL操作將被自動納入此事務。應用B只需要安裝TXC的客戶端包並進行少量必要的配置。BS1不需要爲此做任何代碼修改。
爲了避免服務在不知情的情況下被捲入事務，一個HSF服務在缺省情況下是拒絕事務傳播的，即接受事務傳播的配置必須顯示地被打開。
該事務傳播可以是多分支（A調用B、A調用C，以此類推）、多層級（A調用B、B調用C，以此類推）的。對於多層級的傳播，要求每層服務都部署了TXC，並且顯示地配置了接受事務傳播，否則傳播會被中斷，不能進入後面的所有層級。
該事務傳播可以是異步的，但在事務提交前，應用必須保證所有異步操作都必須返回。
當TXC Server有一臺宕機時，當前有部分事務會被回滾，但新發起的事務仍能繼續進行。
當TXC Server有多臺同時宕機時，會有部分事務被回滾，部分新發起的事務不能繼續進行。
當TXC Client所在的應用機器宕機時，該機器上發起或參與的所有事務都將被回滾，其中該機器發起的事務可能會被另一臺同一應用、同一數據庫DBKey的機器回滾（如果有的話）。
TXC各個Server之間是share nothing的架構，因此可以水平擴展。
各應用會隨機地連接到一個TXC Server。當新增TXC Server時，Diamond配置會被推送，負載很快會重新平衡。
TXC不會保留、分析業務數據。TXC僅僅在事務進行中會暫存一部分業務數據到業務數據庫，以準備可能的回滾。TXC不會試圖去理解這些數據背後的業務含義。當事務結束後這些數據會被立刻刪除。
TXC的不同模式之間可以互相兼容。即，如果應用A是AT模式，通過HSF調用配置爲MT（或RT）模式的B服務，A與B的所有寫SQL操作可以被包含到同一個TXC分佈式事務中。以此類推。
TXC在部署上分兩個部分，TXC Server和TXC Client。
TXC Server是若干個獨立的服務器，通常由北京中間件團隊維護，但特殊情況下也可以部署在應用方自己的機房內，由應用方自己維護。
TXC Client是一個或多個二分包，應用需要依賴這些二方包，並通過若干配置（至少需要能通過配置連接上一個TXC Server）使用分佈式事務功能。