Java帝國之宮廷內(nèi)斗
1.JDBC大臣
自從和東海之濱的數(shù)據(jù)庫聯(lián)合酋長國締結了合作協(xié)議以后， IO大臣就退居二線了。
他本來也想把JDBC也劃歸自己管理， 奈何國王頭腦發(fā)熱、竟然任命了新的JDBC大臣， 專門負責這一攤事兒。
JDBC大臣經(jīng)常在早朝上給國王吹風： “ 陛下， 我們的JDBC設計的非常好， 別看什么Hibernate, Mybatis 是現(xiàn)在的事實標準， 他們底層都在用我們的JDBC接口。 ”
國王贊許地頻頻點頭，似乎忘記了這是躲在角落中IO大臣的功績。
IO大臣咬牙切齒又無可奈何。
這天JDBC又在給國王安利關系數(shù)據(jù)庫的好處： “陛下，這關系數(shù)據(jù)庫相比于簡單的文件系統(tǒng)有個巨大的好處，就是支持事務。”
聽到JDBC大臣又在貶低自己負責的部門， IO大臣怒火中燒。
國王問道：“什么是事務，要事務干嘛? ”
“我舉個通俗的例子你就明白了， 假設IO大臣要給我轉賬100塊錢， 他的數(shù)據(jù)庫賬戶要扣掉100塊， 我的賬戶要增加100塊， 這就涉及到兩個操作， 這兩個操作要么全部完成，要么一個都不做，只有這樣才能保證數(shù)據(jù)的一致性， 這就是一個事務。數(shù)據(jù)庫聯(lián)合酋長國有個對事務總結了4個特性： 原子性(Atomicity) ，一致性(Consistency), 隔離性(Isolation) , 持久性(Durability) , 簡稱ACID, 要不我再給詳細的解釋下?”
國王連忙擺手：“不不不， 別拿這些細節(jié)煩我， 你就告訴我們的臣民怎么去使用就行了”
JDBC大臣說： “這個很簡單， 默認情況下我們的JDBC都會把對數(shù)據(jù)庫的操作認為是一個事務， 當然臣民們也可以設置成手工的方式， 手工地提交和回滾事務。不管哪種方式，都是非常簡單的 。”
國王說： “那就好， 愛卿辛苦了， 還有事嗎? 有事啟奏，無事退朝。”
2 .密謀
IO大臣回到家中，依然感覺火氣難平， 招來幕僚商談。
InputStream說： “大人， 這JDBC大臣雖然猖狂， 我們卻暫時拿他沒辦法， 現(xiàn)在都是Web時代， 哪個應用不用數(shù)據(jù)庫啊? ”
“難道就讓他這么猖獗下去? ”
InputReader足智多謀： “我倒是有一計， 只是得等待時機。 ”
“什么時機?”
“你看今天JDBC那廝提到了事務， 但是這個事務只是在一個數(shù)據(jù)庫中有用啊， 如果需要跨數(shù)據(jù)庫怎么辦? 比如我的賬號存在數(shù)據(jù)庫A, 你的賬號在數(shù)據(jù)庫B, 那轉賬的時候怎么辦? 怎么實現(xiàn)什么ACID ? ”
InputStream表示不同意： “誰會這么傻， 把我們的賬號信息放到兩個數(shù)據(jù)庫當中? ”
“這就是時候未到， 現(xiàn)在大部分的應用數(shù)據(jù)量都不大， 放到一個數(shù)據(jù)庫中綽綽有余，等到數(shù)據(jù)量大到一定程度，勢必要拆分數(shù)據(jù)庫，就會出現(xiàn)跨數(shù)據(jù)庫的事務， 到那個時候我們的機會就來了， 我們準備好解決方案， 參那廝一本， 不信扳不倒他!”
IO大臣拍板： “好! 就這么辦， 這事離不開數(shù)聯(lián)酋(數(shù)據(jù)庫聯(lián)合酋長國)的支持，我和他們還有交情， 這就派人去，許以重金， 讓他們繼續(xù)和我們合作。”
在IO大臣密謀的同時， JDBC大臣的家中卻是觥籌交錯、鶯歌燕舞。
有識之士如Connection 曾經(jīng)向JDBC大臣提醒過要和數(shù)聯(lián)酋搞好關系， 以便將來有什么不時之需。 可是處于***的JDBC大臣哪能聽得進去?
3 .兩階段提交
InputReader 果然很有遠見， 隨著時間的流逝， Web越來越發(fā)達， 帝國出現(xiàn)了很多巨型網(wǎng)站， 他們的各種數(shù)據(jù)果然是沒法放到一個數(shù)據(jù)庫中了，把大的業(yè)務系統(tǒng)查分成多個數(shù)據(jù)庫勢在必行， 當一個業(yè)務同時操作多個數(shù)據(jù)庫的時候， 沒有分布式事務是做不了的。
正在此時，一個秘密奏章被送到了國王的案頭， 狀告JDBC大臣因循守舊，面對大好的形式不與時俱進，對分布式事務漠不關心，毫無作為。
國王召集朝會，討論分布式事務的問題， 他向JDBC大臣率先發(fā)難： “愛卿， 你聽說過臣民們要求支持分布式事務嗎?”
JDBC大臣慌了： “這。。。 這好像是一撮刁民提的要求吧， 陛下不用理會。”
IO大臣冷笑一聲：“刁民? 我看是良民吧 ! 啟奏陛下， 據(jù)臣所知，帝國有不下百個系統(tǒng)要求支持分布式事務，JDBC大臣竟然連最基本的情況都不知道， 真是毫無作為。”
IO大臣覺得穩(wěn)操勝券，直接撕破了臉。
國王心里明白了幾分， 他直接對IO大臣說： “愛卿，你說說該怎么辦?”
“陛下，當年臣和數(shù)據(jù)庫聯(lián)合酋長國談判的時候， 和他們建立了良好的交情。 前幾天我宴請他們的時候，特別提及了這件事情。 Oracle 告訴臣，這很好辦， 人家別的王國正在討論實施兩階段提交的協(xié)議， 我們也可以參與進來。”
雖然IO大臣已經(jīng)和數(shù)據(jù)庫聯(lián)合酋長國討價還價了很久， 不知道花費了多少金錢，但還是不顯山不漏水、很隨意地說了出來。
JDBC大臣一看IO大臣進入了自己的一畝三分地， 急忙問道： 什么是兩階段提交?
IO大臣不屑地瞥了他一眼， 從袖子中拿出早就準備好的提議，雙手向國王奉上。
國王哪里看得懂，掃了一眼就賜給望眼欲穿的JDBC大臣， 只見上面赫然寫著：
兩階段提交協(xié)議
由于涉及到多個分布式的數(shù)據(jù)庫， 我們特設一個全局的事務管理器，它來負責協(xié)調(diào)各個數(shù)據(jù)庫的事務提交， 為了實現(xiàn)分布式事務，特設兩個階段：
階段1： 全局的事務管理器向各個數(shù)據(jù)庫發(fā)出準備消息。 各個數(shù)據(jù)庫需要在本地把一切都準備好，執(zhí)行操作，鎖住資源， 記錄redo/undo 日志， 但是并不提交， 總而言之，要進入一個時刻準備提交或回滾的狀態(tài)， 然后向全局事務管理器報告是否準備好了。
階段2： 如果所有的數(shù)據(jù)庫都報告說準備好了， 那全局的事務管理器就下命令： 提交， 這時候各個數(shù)據(jù)庫才真正提交 ， 由于之前已經(jīng)萬事具備，只欠東風，只需要快速完成本地提交即可;
如果有任何一個數(shù)據(jù)庫報告說沒準備好， 事務管理器就下命令： 放棄， 這時候各個數(shù)據(jù)庫要執(zhí)行回滾操作， 并且釋放各種在階段1鎖住的資源。
JDBC大臣也是行家，一看就明白了是怎么回事。階段1就是讓大家都準備好，階段2就是迅速提交。
這是一個看起來很美的理想方案，但是他意識到其中有漏洞，自己的幕僚曾經(jīng)告誡過：一旦涉及到分布式，事情就不會那么簡單，任何地方都有失敗的可能。
比如在第二階段，那個事務管理器要是出了問題怎么辦? 人家各個數(shù)據(jù)庫還在等著你發(fā)命令呢? 你遲遲不發(fā)命令，大家都阻塞在那里，不知所措，到底是提交呢?還是不提交呢， 我這里還鎖著資源呢， 遲遲不能釋放，多耽誤事啊 !
還是第二階段，事務管理器發(fā)出的提交命令由于網(wǎng)絡問題，數(shù)據(jù)庫1收到了，數(shù)據(jù)庫2沒收到，這兩個數(shù)據(jù)庫就處于不一致狀態(tài)了， 該怎么處理?
JDBC大臣決心給IO大臣挖個坑：讓你逞能 ! 讓你給老子穿小鞋!
他說：“ 陛下，IO大臣不愧為設計過JDBC協(xié)議的股肱之臣， 臣才學疏淺，深為拜服，特奏請陛下恩準IO大臣再次出山和數(shù)據(jù)庫聯(lián)合酋長國設計出新協(xié)議， 來支持分布式事務。”
國王準奏。
4 .JTA
IO大臣滿心狐疑， 不知道JDBC老頭兒在給自己下什么藥，回到府中和大家商量。
InputReader 眼看自己多年前的計策就要成功，頗為興奮： “管它呢， 只要咱們把這個分布式事務的協(xié)議給制定好，JDBC老兒就得下臺了。”
“對，到時候我們就掌管文件， 網(wǎng)絡，數(shù)據(jù)庫，Java 帝國就是我們IO獨大了” InputStream 開始暢想美好的未來，到時候自己估計至少從5品升為4品。
IO大臣馬上安排和數(shù)據(jù)庫聯(lián)合酋長國的談判，由于之前良好的交情。 這一次協(xié)議很容易就達成了， IO大臣給他起了一個很響亮的名字： Java Transaction API (簡稱JTA)。
這個JTA規(guī)范用起來也比較簡單， 只要獲得一個UserTransaction 就可以操作了，帝國的臣民們根本不用關系底層的協(xié)議細節(jié)：
經(jīng)過國王的批準， JTA正式推廣。
可是令IO大臣萬萬沒有想到的是， 國王在JTA發(fā)布的前夕， 親切地召見了自己和另外一個不知名的官員， 國王關心地說：“愛卿，朕知道你很忙，掌管著網(wǎng)絡和文件操作，為了給你減輕負擔，朕決定任命一個新的JTA大臣來協(xié)助你!”
IO大臣如同五雷轟頂，自己辛辛苦苦的工作完全被無視， 這到底是為什么?
他失魂落魄地回到府中， 好幾天茶飯不思。
還是InputReader 出來安慰了他： “這是陛下的帝王之術， 害怕我們一家坐大， 平衡了一下朝中力量。大人可以放寬心， 你看JDBC大臣也受到了打壓，風光不再了。”
5. 塞翁失馬，焉知非福
JTA并沒有取得像JDBC那樣的廣泛應用， JDBC大臣挖的那個坑現(xiàn)在終于露出了猙獰的面目。
只不過這個坑并沒有讓IO大臣掉進去， 新任的JTA大臣背了黑鍋。
臣民的抗議聲越來越多： 分布式事務伴隨著大量節(jié)點的通信交換， 協(xié)調(diào)者要確定其他節(jié)點是否完成， 加上網(wǎng)絡帶來的超時，導致JTA性能低下， 在高并發(fā)和高性能的場景下舉步維艱。
拜IO大臣的工作所賜， 現(xiàn)在數(shù)據(jù)庫聯(lián)合酋長國的各個部落都支持兩階段提交，很多應用服務器Websphere , Weblogic 等都支持JTA， 可是使用者確是***， 都快成擺設了。
JTA大臣每次上朝都戰(zhàn)戰(zhàn)兢兢， 他是個平庸之輩，雖然四處救火，但是無力解決根本的問題。
現(xiàn)在那些高并發(fā)的系統(tǒng)反而極力避免兩階段提交， 他們繞開JTA大臣， 直接找到了IO大臣訴苦：“大人，你帶領著制定了JTA, 但是這個標準太理想化，完全不符合實情啊! ”
IO大臣說： “不會吧，這不是你們要求的嗎， 用戶A和B的賬號分別在兩個數(shù)據(jù)庫， 當A給B轉賬100塊的時候， 肯定得保證A扣掉100， 然后B增加100啊。”
“這就是官府的想法， 總是想著讓兩個數(shù)據(jù)庫保證實時的一致性(強一致性)， 為了達到這個目標，JTA付出的代價太高了。 我們現(xiàn)在不想這么干了。 我們可以忍受一段時間的不一致，只有最終一致就行。 比方說A給B轉100元， A 中的錢已經(jīng)扣除， 但是B中不會實時地增加，過段時間能保證增加就行了”
“最終一致性? 有點意思!” ，想到Java 帝國的官方標準總是被臣民們所建立的事實標準所打敗，敏銳的IO大臣立刻看到了背后的機遇， 他決定這一次要聯(lián)合民間力量，再次反攻， 一舉搞掉JDBC大臣和JTA大臣。
想到這里， IO大臣得意地笑了......
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉載請通過作者微信公眾號coderising獲取授權】
