Java帝国之宫廷内斗

kinghitomi 2年前
   <p><img src="https://simg.open-open.com/show/0d47b4be4060f8b273f387303832b85b.jpg"></p>    <h2>1.JDBC大臣</h2>    <p>自从和东海之滨的数据库联合酋长国缔结了合作协议以后, IO大臣就退居二线了。</p>    <p>他本来也想把JDBC也划归自己管理, 奈何国王头脑发热、竟然任命了新的JDBC大臣, 专门负责这一摊事儿。</p>    <p>JDBC大臣经常在早朝上给国王吹风: “ 陛下, 我们的JDBC设计的非常好, 别看什么Hibernate, Mybatis 是现在的事实标准, 他们底层都在用我们的JDBC接口。 ”</p>    <p>国王赞许地频频点头,似乎忘记了这是躲在角落中IO大臣的功绩。</p>    <p>IO大臣咬牙切齿又无可奈何。</p>    <p>这天JDBC又在给国王安利关系数据库的好处: “陛下,这关系数据库相比于简单的文件系统有个巨大的好处,就是支持事务。”</p>    <p>听到JDBC大臣又在贬低自己负责的部门, IO大臣怒火中烧。</p>    <p>国王问道:“什么是事务,要事务干嘛? ”</p>    <p>“我举个通俗的例子你就明白了, 假设IO大臣要给我转账100块钱, 他的数据库账户要扣掉100块, 我的账户要增加100块, 这就涉及到两个操作, 这两个操作要么全部完成,要么一个都不做,只有这样才能保证数据的一致性, 这就是一个事务。数据库联合酋长国有个对事务总结了4个特性: 原子性(Atomicity) ,一致性(Consistency), 隔离性(Isolation) , 持久性(Durability) , 简称ACID, 要不我再给详细的解释下?”</p>    <p>国王连忙摆手:“不不不, 别拿这些细节烦我, 你就告诉我们的臣民怎么去使用就行了”</p>    <p>JDBC大臣说: “这个很简单, 默认情况下我们的JDBC都会把对数据库的操作认为是一个事务, 当然臣民们也可以设置成手工的方式, 手工地提交和回滚事务。不管哪种方式,都是非常简单的 。”</p>    <p>国王说: “那就好, 爱卿辛苦了, 还有事吗? 有事启奏,无事退朝。”</p>    <h2>2 .密谋</h2>    <p>IO大臣回到家中,依然感觉火气难平, 招来幕僚商谈。</p>    <p>InputStream说: “大人, 这JDBC大臣虽然猖狂, 我们却暂时拿他没办法, 现在都是Web时代, 哪个应用不用数据库啊? ”</p>    <p>“难道就让他这么猖獗下去? ”</p>    <p>InputReader足智多谋: “我倒是有一计, 只是得等待时机。 ”</p>    <p>“什么时机?”</p>    <p>“你看今天JDBC那厮提到了事务, 但是这个事务只是在一个数据库中有用啊, 如果需要跨数据库怎么办? 比如我的账号存在数据库A, 你的账号在数据库B, 那转账的时候怎么办? 怎么实现什么ACID ? ”</p>    <p>InputStream表示不同意: “谁会这么傻, 把我们的账号信息放到两个数据库当中? ”</p>    <p>“这就是时候未到, 现在大部分的应用数据量都不大, 放到一个数据库中绰绰有余,等到数据量大到一定程度,势必要拆分数据库,就会出现跨数据库的事务, 到那个时候我们的机会就来了, 我们准备好解决方案, 参那厮一本, 不信扳不倒他!”</p>    <p>IO大臣拍板: “好! 就这么办, 这事离不开数联酋(数据库联合酋长国)的支持,我和他们还有交情, 这就派人去,许以重金, 让他们继续和我们合作。”</p>    <p>在IO大臣密谋的同时, JDBC大臣的家中却是觥筹交错、莺歌燕舞。</p>    <p>有识之士如Connection 曾经向JDBC大臣提醒过要和数联酋搞好关系, 以便将来有什么不时之需。 可是处于巅峰的JDBC大臣哪能听得进去?</p>    <h2>3 .两阶段提交</h2>    <p>InputReader 果然很有远见, 随着时间的流逝, Web越来越发达, 帝国出现了很多巨型网站, 他们的各种数据果然是没法放到一个数据库中了,把大的业务系统查分成多个数据库势在必行, 当一个业务同时操作多个数据库的时候, 没有分布式事务是做不了的。</p>    <p>正在此时,一个秘密奏章被送到了国王的案头, 状告JDBC大臣因循守旧,面对大好的形式不与时俱进,对分布式事务漠不关心,毫无作为。</p>    <p>国王召集朝会,讨论分布式事务的问题, 他向JDBC大臣率先发难: “爱卿, 你听说过臣民们要求支持分布式事务吗?”</p>    <p>JDBC大臣慌了: “这。。。 这好像是一撮刁民提的要求吧, 陛下不用理会。”</p>    <p>IO大臣冷笑一声:“刁民? 我看是良民吧 ! 启奏陛下, 据臣所知,帝国有不下百个系统要求支持分布式事务,JDBC大臣竟然连最基本的情况都不知道, 真是毫无作为。”</p>    <p>IO大臣觉得稳操胜券,直接撕破了脸。</p>    <p>国王心里明白了几分, 他直接对IO大臣说: “爱卿,你说说该怎么办?”</p>    <p>“陛下,当年臣和数据库联合酋长国谈判的时候, 和他们建立了良好的交情。 前几天我宴请他们的时候,特别提及了这件事情。 Oracle 告诉臣,这很好办, 人家别的王国正在讨论实施两阶段提交的协议, 我们也可以参与进来。”</p>    <p>虽然IO大臣已经和数据库联合酋长国讨价还价了很久, 不知道花费了多少金钱,但还是不显山不漏水、很随意地说了出来。</p>    <p>JDBC大臣一看IO大臣进入了自己的一亩三分地, 急忙问道: 什么是两阶段提交?</p>    <p>IO大臣不屑地瞥了他一眼, 从袖子中拿出早就准备好的提议,双手向国王奉上。</p>    <p>国王哪里看得懂,扫了一眼就赐给望眼欲穿的JDBC大臣, 只见上面赫然写着:</p>    <p>两阶段提交协议</p>    <p>由于涉及到多个分布式的数据库, 我们特设一个全局的事务管理器,它来负责协调各个数据库的事务提交, 为了实现分布式事务,特设两个阶段:</p>    <p>阶段1: 全局的事务管理器向各个数据库发出准备消息。 各个数据库需要在本地把一切都准备好,执行操作,锁住资源, 记录redo/undo 日志, 但是并不提交, 总而言之,要进入一个时刻准备提交或回滚的状态, 然后向全局事务管理器报告是否准备好了。</p>    <p>阶段2: 如果所有的数据库都报告说准备好了, 那全局的事务管理器就下命令: 提交, 这时候各个数据库才真正提交 , 由于之前已经万事具备,只欠东风,只需要快速完成本地提交即可;</p>    <p>如果有任何一个数据库报告说没准备好, 事务管理器就下命令: 放弃, 这时候各个数据库要执行回滚操作, 并且释放各种在阶段1锁住的资源。</p>    <p><img src="https://simg.open-open.com/show/aeed2990b937ad6a770c0d752201aa28.jpg"></p>    <p>JDBC大臣也是行家,一看就明白了是怎么回事。阶段1就是让大家都准备好,阶段2就是迅速提交。</p>    <p>这是一个看起来很美的理想方案,但是他意识到其中有漏洞,自己的幕僚曾经告诫过:一旦涉及到分布式,事情就不会那么简单,任何地方都有失败的可能。</p>    <p>比如在第二阶段,那个事务管理器要是出了问题怎么办? 人家各个数据库还在等着你发命令呢? 你迟迟不发命令,大家都阻塞在那里,不知所措,到底是提交呢?还是不提交呢, 我这里还锁着资源呢, 迟迟不能释放,多耽误事啊 !</p>    <p>还是第二阶段,事务管理器发出的提交命令由于网络问题,数据库1收到了,数据库2没收到,这两个数据库就处于不一致状态了, 该怎么处理?</p>    <p>JDBC大臣决心给IO大臣挖个坑:让你逞能 ! 让你给老子穿小鞋!</p>    <p>他说:“ 陛下,IO大臣不愧为设计过JDBC协议的股肱之臣, 臣才学疏浅,深为拜服,特奏请陛下恩准IO大臣再次出山和数据库联合酋长国设计出新协议, 来支持分布式事务。”</p>    <p>国王准奏。</p>    <h2>4 .JTA</h2>    <p>IO大臣满心狐疑, 不知道JDBC老头儿在给自己下什么药,回到府中和大家商量。</p>    <p>InputReader 眼看自己多年前的计策就要成功,颇为兴奋: “管它呢, 只要咱们把这个分布式事务的协议给制定好,JDBC老儿就得下台了。”</p>    <p>“对,到时候我们就掌管文件, 网络,数据库,Java 帝国就是我们IO独大了” InputStream 开始畅想美好的未来,到时候自己估计至少从5品升为4品。</p>    <p>IO大臣马上安排和数据库联合酋长国的谈判,由于之前良好的交情。 这一次协议很容易就达成了, IO大臣给他起了一个很响亮的名字: Java Transaction API (简称JTA)。</p>    <p>这个JTA规范用起来也比较简单, 只要获得一个UserTransaction 就可以操作了,帝国的臣民们根本不用关系底层的协议细节:</p>    <p><img src="https://simg.open-open.com/show/dc6a873193a006e8bc0365767d886bd6.jpg"></p>    <p>经过国王的批准, JTA正式推广。</p>    <p>可是令IO大臣万万没有想到的是, 国王在JTA发布的前夕, 亲切地召见了自己和另外一个不知名的官员, 国王关心地说:“爱卿,朕知道你很忙,掌管着网络和文件操作,为了给你减轻负担,朕决定任命一个新的JTA大臣来协助你!”</p>    <p>IO大臣如同五雷轰顶,自己辛辛苦苦的工作完全被无视, 这到底是为什么?</p>    <p>他失魂落魄地回到府中, 好几天茶饭不思。</p>    <p>还是InputReader 出来安慰了他: “这是陛下的帝王之术, 害怕我们一家坐大, 平衡了一下朝中力量。大人可以放宽心, 你看JDBC大臣也受到了打压,风光不再了。”</p>    <h2>5. 塞翁失马,焉知非福</h2>    <p>JTA并没有取得像JDBC那样的广泛应用, JDBC大臣挖的那个坑现在终于露出了狰狞的面目。</p>    <p>只不过这个坑并没有让IO大臣掉进去, 新任的JTA大臣背了黑锅。</p>    <p>臣民的抗议声越来越多: 分布式事务伴随着大量节点的通信交换, 协调者要确定其他节点是否完成, 加上网络带来的超时,导致JTA性能低下, 在高并发和高性能的场景下举步维艰。</p>    <p>拜IO大臣的工作所赐, 现在数据库联合酋长国的各个部落都支持两阶段提交,很多应用服务器Websphere , Weblogic 等都支持JTA, 可是使用者确是寥寥无几, 都快成摆设了。</p>    <p>JTA大臣每次上朝都战战兢兢, 他是个平庸之辈,虽然四处救火,但是无力解决根本的问题。</p>    <p>现在那些高并发的系统反而极力避免两阶段提交, 他们绕开JTA大臣, 直接找到了IO大臣诉苦:“大人,你带领着制定了JTA, 但是这个标准太理想化,完全不符合实情啊! ”</p>    <p>IO大臣说: “不会吧,这不是你们要求的吗, 用户A和B的账号分别在两个数据库, 当A给B转账100块的时候, 肯定得保证A扣掉100, 然后B增加100啊。”</p>    <p>“这就是官府的想法, 总是想着让两个数据库保证实时的一致性(强一致性), 为了达到这个目标,JTA付出的代价太高了。 我们现在不想这么干了。 我们可以忍受一段时间的不一致,只有最终一致就行。 比方说A给B转100元, A 中的钱已经扣除, 但是B中不会实时地增加,过段时间能保证增加就行了”</p>    <p>“最终一致性? 有点意思!” ,想到Java 帝国的官方标准总是被臣民们所建立的事实标准所打败,敏锐的IO大臣立刻看到了背后的机遇, 他决定这一次要联合民间力量,再次反攻, 一举搞掉JDBC大臣和JTA大臣。</p>    <p>想到这里, IO大臣得意地笑了......</p>    <p> </p>    <p>来自:http://zhuanlan.51cto.com/art/201708/548219.htm</p>    <p> </p>