目錄
1，事務(wù)和分布式事務(wù)介紹
2，JTA
3，TCC
事務(wù)和分布式事務(wù)介紹
之前和一個朋友聊天，聊到工作，他最近在為項目上出現(xiàn)的問題很苦惱，情況我聽了之后，就是分布式事務(wù)的問題。遂準備許久，整理成文檔，與朋友分享。
1，事務(wù)：訪問數(shù)據(jù)庫的一個操作序列,ACID的特性
2，分布式事務(wù)：多個中間件之間的一個操作序列,比如操作了兩個數(shù)據(jù)庫，MQ，或許兩個不同的系統(tǒng)等等
3，單體應(yīng)用在一個JVM中，對一個數(shù)據(jù)庫進行CRUD，利用@Transaction就可以保持事務(wù)的一致性，如果要對兩個數(shù)據(jù)庫進行CRUD,就需要JTA的相關(guān)框架，如atomikos，這個是有免費版的；在分布式應(yīng)用中，就需要TCC的相關(guān)框架，如atomikos的收費版，tcc-transaction，支付寶XTC等等
JTA
JTA是標準的兩階段提交，第一個階段預提交，將提交結(jié)果交給協(xié)調(diào)器，第二個階段是協(xié)調(diào)器根據(jù)結(jié)果，如果兩個都是成功那么久commit,否詞cancle，在這個過程中會鎖表，如果要關(guān)聯(lián)的數(shù)據(jù)庫比較，多，那么JTA時間會很長，會長時間占用資源，效率自然就不高了
TCC
在說TCC之前，首先要了解一下CAP理論
C 一致性 A 可用性 P分區(qū)容忍性
這三個中間只能滿足兩者（外國一個牛人證實的，不信的可以去查，我信），P是一定要滿足的，為什么呢？分布式系統(tǒng)，宕掉2三臺機器，還要滿足能正常運行，這是必須的，所以P就是一定要的了，那么就只有CP或者是AP了，怎么在C和A中間平衡，就是一門藝術(shù)了。
BASE理論（柔性事務(wù)）的出現(xiàn)很好的平衡了C和A,為什么這么說呢？
BA:基本可用，怎么理解呢？我是這么理解的，比如訪問了一次，發(fā)現(xiàn)500了，那么刷一下頁面好了，這就是基本可用。
S:soft state 軟狀態(tài)，中間狀態(tài)
E:最終一致，經(jīng)過中間狀態(tài)之后，最終要達到最終一致。
TCC是什么呢？
兩階段補償型方案 try階段--confirm階段--cancle階段
說了這么多理論，解決方案呢？
1，基于MQ的補償方案，基于MQ，讓被調(diào)用方都去訂閱調(diào)用方的消息，消息做重試，冪等，消息中間狀態(tài)，要說的東西挺多的，畫個圖：
解釋：1，預發(fā)送消息到消息服務(wù)中心，消息狀態(tài)為預發(fā)送狀態(tài)
2，將消息狀態(tài)由與發(fā)送修改為發(fā)送
3，消息服務(wù)中心，將消息發(fā)送到MQ
4，消費方訂閱消費消息
這里面有一個中間狀態(tài)：預發(fā)送狀態(tài)，達到最終一致的補償機制，這樣消息就能可靠的被消費，補償有很多方式：日志，人工(郵件/短信/Excel)等等
2，TCC兩階段補償型方案
就拿之前的一個項目案例說明：大學生在線選房，場景是這樣的：學生選了床位，還需選擇臥具用品。要么床位和臥具都成功，要么都失敗。
try階段：先調(diào)用公寓管理系統(tǒng)將床位鎖定（預留），在調(diào)用倉管鎖定預留臥具
confirm階段：如果兩者都預留成功，則提交
cancle階段：如果有一個預留失敗，則取消
====這里不就是JTA嗎？===
像但絕對不是，JTA是鎖表的，這個沒有鎖表，所以TCC增加了系統(tǒng)的吞吐量，沒有過多的提高單次的執(zhí)行效率。
看一下tcc-transaction官方文檔，恍然大悟了嗎？
其實這個框架就幫我們做了confirm和cancle階段（第二階段），將這兩個方法寫到try方法的頭上，就ok了，其他就交給框架吧。
分布式事務(wù)重要概念：最終一致，補償，兩階段提交，中間狀態(tài)。理解這幾個概念，分布式事務(wù)也就不難了，其實在我們的實際工作中已經(jīng)用到了這種分布式事務(wù)，我們沒有發(fā)現(xiàn)而已，總結(jié)一下，溫故而知新。
望指正，不吝賜教
