GoldenDB事務(wù)一致性處理機(jī)制

1、GoldenDB事務(wù)一致性處理機(jī)制介紹技術(shù)創(chuàng)新 變革未來(lái)AgendaGoldenDB 數(shù)據(jù)庫(kù)架構(gòu)GoldenDB 事務(wù)機(jī)制事務(wù)處理模塊優(yōu)化實(shí)踐GoldenDB是安全可靠的金融級(jí)交易型分布式數(shù)據(jù)庫(kù)2007201120142015201620172018EBASEEBASE-MEMDHSSGoldenDBGoldenDB 1.0GoldenDB 2.0GoldenDB 3.0GoldenDB 4.0分布式數(shù)據(jù)庫(kù) 雛形啟動(dòng)研發(fā)金融級(jí)分布式數(shù)據(jù)庫(kù)正式發(fā)布 并在銀行商用多家銀行商用投產(chǎn) 政企行業(yè)規(guī)模發(fā)貨金融核心交易性能超過(guò)40000TPS大型銀行核心業(yè)務(wù) 并網(wǎng)運(yùn)行2002文件數(shù)據(jù)庫(kù)內(nèi)存數(shù)據(jù)庫(kù) 百萬(wàn)套設(shè)備

2、商用 千萬(wàn)套單板商用17年厚積薄發(fā)100%代碼掌控100+發(fā)明專(zhuān)利APP1數(shù)據(jù)節(jié)點(diǎn)集群1DB-MDB-SDB-MDB-S數(shù)據(jù)節(jié)點(diǎn)集群2DB-MDB-SDB-MDB-S數(shù)據(jù)節(jié)點(diǎn)集群nDB-MDB-S計(jì)算節(jié)點(diǎn)集群管理節(jié) 點(diǎn)DBProxy 1DBProxy 2APP2ODBC / JDBCODBC / JDBC客戶端接入層全局事務(wù) 管理節(jié)點(diǎn)DBProxy nAPPNODBC/JDBCGoldenDB分布式數(shù)據(jù)庫(kù)總體架構(gòu)實(shí)時(shí)一致的 分布式事務(wù)控制同城異地災(zāi)備 一致的備份恢復(fù)線性橫向擴(kuò)展 聯(lián)機(jī)數(shù)據(jù)重分布豐富的監(jiān)控體系 完善的運(yùn)維能力GoldenDB數(shù)據(jù)庫(kù)滿足金融核心的關(guān)鍵要求AgendaGoldenDB

3、 數(shù)據(jù)庫(kù)架構(gòu)GoldenDB 事務(wù)機(jī)制事務(wù)處理模塊優(yōu)化實(shí)踐、單機(jī)數(shù)據(jù)庫(kù)分布式數(shù)據(jù)庫(kù)原子性：多條記錄的多次操作要 么一起成功，要么一起失敗。原子性：多個(gè)數(shù)據(jù)分片上的多次操作要么 一起成功，要么一起失敗。隔離性：不同連接(處理線程或 進(jìn)程)不會(huì)相互訪問(wèn)到未提交事 務(wù)的數(shù)據(jù)。隔離性：多個(gè)計(jì)算節(jié)點(diǎn)上的不同連接不會(huì) 相互訪問(wèn)到在多個(gè)數(shù)據(jù)分片內(nèi)未提交事務(wù) 的數(shù)據(jù)。持久性：事務(wù)提交前必須先將日 志落盤(pán)，機(jī)器重啟后不丟失數(shù)據(jù)持久性：事務(wù)提交前必須將日志在分片主。從節(jié)點(diǎn)都得到復(fù)制，主節(jié)點(diǎn)故障時(shí)從節(jié)點(diǎn) 上仍能找回?cái)?shù)據(jù)。AICD單機(jī)數(shù)據(jù)庫(kù)：保證事務(wù)在事務(wù)內(nèi)(原子性-A)、事務(wù)間(隔離性-I)和故障時(shí)(持久性-D)

4、的一致性(C)。分布式數(shù)據(jù)庫(kù)：將數(shù)據(jù)庫(kù)事務(wù)的ACID理論延伸到分布式架構(gòu)下。tableDB1(主)DB2(主)DB3(主)DB1(從)DB2(從)DB3(從)APP1APP2APP3DBProxy1DBProxy2DBProxy3DBbilnolgogtableAPP1事務(wù)理論的分布式延伸要實(shí)現(xiàn)分布式事務(wù)的實(shí)時(shí)一致性（保證ACID ），難點(diǎn)在哪？部分DB提交失敗，如何保證全局事務(wù)的原子性(A)？并發(fā)訪問(wèn)時(shí)，每個(gè)事務(wù)都不知道其他事務(wù)的狀態(tài)，如何保證事務(wù)之間的隔離性(I)？以轉(zhuǎn)賬交易為例: 交易前2個(gè)賬戶資金余額各100，事務(wù)T1從賬戶1轉(zhuǎn)賬50到賬 戶2;在事務(wù)T1提交期間，由于DB1和DB2提

5、交時(shí)間有空隙，若此時(shí)事務(wù)T2讀取2個(gè)賬戶的余額，會(huì)發(fā)現(xiàn)余額之和是50+100=150。存在事務(wù)T1對(duì)賬戶1上扣錢(qián)成功，給賬戶2加錢(qián)失敗的情況。賬戶1減50賬戶2加50賬戶1提交查詢賬戶1和DB1DB2APP1APP2DBProxy賬戶1向賬戶2轉(zhuǎn)賬50元事務(wù)T1事務(wù)T2敗賬戶2提交，但提交失額額賬戶2的余額 查詢賬戶1余余額50查詢賬戶2余余額100分布式事務(wù)的難點(diǎn) 參與者在投贊成票之前可以單方面取消事務(wù)； 參與者投票之后不能改變它的投票； 處于READY狀態(tài)的參與者依賴于協(xié)調(diào)者的決 策，提交或取消事務(wù)； 協(xié)調(diào)者根據(jù)全局規(guī)則進(jìn)行全局提交或者全局 取消； 參與者和協(xié)調(diào)者在某些狀態(tài)會(huì)等待消息，需

6、要啟動(dòng)定時(shí)器進(jìn)行監(jiān)控；正常的提交流程，日志寫(xiě)入數(shù)量為2N+3，消息數(shù)為4N，其中N為參與節(jié)點(diǎn)的數(shù)量；通過(guò)2PC協(xié)議保障原子性對(duì)業(yè)務(wù)的侵入性較大，所有業(yè)務(wù)都要增加反向操作邏輯/增加額外中間件處理過(guò)程中數(shù)據(jù)存在短暫不一致或更新延后，原子性不能100%保障 節(jié)點(diǎn)級(jí)故障需要不斷重試，如不斷失敗須人為干預(yù)才能解決事務(wù)單元事務(wù)開(kāi)始查看A賬戶是否100A賬戶減100事務(wù)結(jié)束確認(rèn)消息發(fā)送消息發(fā)送者發(fā)消息消息發(fā)送者事務(wù)單元事務(wù)開(kāi)始B賬戶加100插入去重表事務(wù)結(jié)束超時(shí)不斷重試消息集群主業(yè)務(wù)數(shù)據(jù)庫(kù)業(yè)務(wù)活動(dòng)管理器 活動(dòng)日志啟動(dòng)業(yè)務(wù)活動(dòng) 登記業(yè)務(wù)操作提交/回滾業(yè)務(wù)活動(dòng)Try Confirm Cancel數(shù)據(jù)節(jié)點(diǎn)1Try

7、 Confirm Cancel數(shù)據(jù)節(jié)點(diǎn)2從 業(yè) 務(wù)從 業(yè) 務(wù)通過(guò)業(yè)務(wù)改造保障原子性A=100from binlog:A 50-100A給B轉(zhuǎn)賬50元A-50B+50A=50OkA=100B=100FailureB=150A=50Grobol RollbackB=100RollbackCommitto binlog:A 100-50基于樂(lè)觀鎖的分布式一階段提交輔助自動(dòng)補(bǔ)償機(jī)制: 一階段提交 自動(dòng)補(bǔ)償回滾優(yōu)點(diǎn)： 應(yīng)用層無(wú)需實(shí)現(xiàn)補(bǔ)償邏輯。 失敗回滾是少數(shù)情況，整體性能高于兩階段提交。GoldenDB事務(wù)原子性實(shí)現(xiàn)機(jī)制通過(guò)回 滾進(jìn)行 事務(wù)補(bǔ) 償定位遍歷生成執(zhí)行提升回 滾性能表定義 緩存預(yù)分析 并行查找

8、共享內(nèi)存SQL格式反向 binlogkey值利 用已提交事務(wù)回滾實(shí)現(xiàn)和優(yōu)化 寫(xiě)寫(xiě)沖突，處理不當(dāng)導(dǎo)致 臟寫(xiě) 丟失回滾（T1W、T2W、T1A，基于被回滾的數(shù)據(jù)做了update） 寫(xiě)讀沖突，處理不當(dāng)導(dǎo)致 臟讀（臟讀、不可重復(fù)讀、讀偏序、幻讀） 讀寫(xiě)沖突，處理不當(dāng)導(dǎo)致 臟寫(xiě) 丟失更新（T1R、T2W、T1W，T2W被覆蓋） 寫(xiě)偏序，一種違反語(yǔ)義的異常（黑白球問(wèn)題，發(fā)生于快照級(jí)別隔離）導(dǎo)致異常的原因是因?yàn)椴l(fā)調(diào)度未等價(jià)于任意一種串行處理結(jié)果事務(wù)隔離性的各種異常引自論文A Critique of ANSI SQL Isolation Levels隔離級(jí)別及對(duì)應(yīng)的現(xiàn)象 嚴(yán)格按照串行順序執(zhí)行voltdb、R

9、edis 運(yùn)用SS2PL技術(shù)，加鎖解決幻讀MySQL、SQL Server、Informix 可串行化的快照隔離SSI，解決寫(xiě)偏序PostgreSQL、FoundationDB達(dá)到可串行化隔離級(jí)別的三種實(shí)現(xiàn)方式鎖的數(shù)量開(kāi)始結(jié)束事務(wù)持續(xù)時(shí)間增長(zhǎng)收縮Eswaran等人已經(jīng)證明：遵守2PL算法的 并發(fā)調(diào)度一定是可串行化的。2PL-Lock Point確定LockPoint比較困難commit時(shí)釋放寫(xiě)鎖S2PL-commit時(shí)釋放讀、寫(xiě)鎖SS2PL通過(guò)2PL進(jìn)行事務(wù)并發(fā)控制引入全局事務(wù)管理器（GTM：Global Transaction Manager）實(shí)現(xiàn)全局事務(wù)的隔離性，并協(xié)助實(shí)現(xiàn)全 局事務(wù)的原子

10、性。關(guān)鍵說(shuō)明： GTM統(tǒng)一管理全局事務(wù) GTID的生命周期就是全局事務(wù)的生命周期IDGTIDAcntA100250C1001200IDGTIDAcntB1002100D1001200oldA1001100newA100250oldB1001100newB1002150Table:AccountTable:AccountbinlogGTID10021003C 1002R 1002DB2DBProxyGTMA-50GTID:1002begin;update Account set Acnt = Acnt-50 where ID = A；update Account set Acnt = Acnt+

11、50 where ID = B；commit;select Acnt from Account where ID in(A, B);ReleaseAPP1 JDBC/ODBCAPP2 JDBC/ODBC12 Create3DB14binlog563？B+50 GTID:1002引入GTM進(jìn)行事務(wù)并發(fā)控制SS2PL：事務(wù)提交的的時(shí)候才釋放讀鎖和寫(xiě)鎖GTM封鎖：事務(wù)提交之前，所有的GTID相關(guān)的數(shù)據(jù)都不能被讀取和修改活躍事務(wù)列表里的GTID，相當(dāng)于寫(xiě)鎖。-保障了寫(xiě)寫(xiě)和寫(xiě)讀沖突下的數(shù)據(jù)一致性。通過(guò)對(duì)讀操作顯式加鎖，達(dá)到嚴(yán)格的SS2PL效果。-保障了讀寫(xiě)沖突下的數(shù)據(jù)一致性。與SS2PL的比較現(xiàn)象：DB

12、Proxy查詢到的活躍事務(wù)列表永遠(yuǎn)是舊的；DBProxy基于活躍事務(wù)列表做 的判斷永遠(yuǎn)都是不準(zhǔn)確的。解決辦法：將所有的可能性沖突都認(rèn)為是沖突。在返回活躍事務(wù)列表中，增加Max_GITD，Proxy判斷GTID大于Max_GITD， 也認(rèn)為是存在沖突的。預(yù)鎖機(jī)制寫(xiě)一致性處理滿足條件的記錄上無(wú)鎖滿足條件的記錄上有鎖GTID不活躍GTID活躍事務(wù)處理總結(jié)讀一致性處理臟讀讀已提交有排它鎖無(wú)排它鎖GTID不活躍GTID活躍可重復(fù)讀有排它鎖無(wú)排它鎖可序列化加共享鎖無(wú)沖突加共享鎖有沖突GTID不活躍GTID活躍GTID不活躍GTID活躍事務(wù)處理總結(jié)AgendaGoldenDB 數(shù)據(jù)庫(kù)架構(gòu)GoldenDB 事

13、務(wù)機(jī)制事務(wù)處理模塊優(yōu)化實(shí)踐待優(yōu)化流程：GTID申請(qǐng)/釋放GTID列表查詢待優(yōu)化瓶頸點(diǎn)：GTM需要對(duì)GTID的變化實(shí)時(shí)落盤(pán)，一次寫(xiě)盤(pán)大概1s，理論上限100萬(wàn) TPS，能否突破？Proxy和GTM之間的消息交互，對(duì)網(wǎng)絡(luò)資源消耗過(guò)大，理論瓶頸1.25GB 帶寬如何利用？?jī)?yōu)化方向減少交互次數(shù)，降低交互數(shù)據(jù)量GTMDBProxycreate GTIDcreate GTIDcreate GTIDcreate GTID create GTIDGTMDBProxycreate 5 GTIDsGTMDBProxyrelease GTID1GTMDBProxyrelease GTID14、10release G

14、TID2release GTID3release GTID4 release GTID10申請(qǐng)/釋放GTID優(yōu)化：Proxy批量請(qǐng)求GTMDBProxyquery GTID ListThread1Thread2 Thread3 Thread4 Thread5query GTID Listquery GTID Listquery GTID Listquery GTID ListGTMProxy子線程DBProxyThread1Thread2 Thread3 Thread4 Thread5query GTID Listquery GTID Listquery GTID Listquery GTID

15、 Listquery GTID Listquery GTID List查詢GTID列表優(yōu)化：Proxy進(jìn)行組提交代理線程匯總sql線程的請(qǐng)求，使用一份活躍事務(wù)列表應(yīng)答。當(dāng)在途請(qǐng)求沒(méi)有返回時(shí)，代理線程不會(huì)發(fā)送新的查詢請(qǐng)求。DBProxy1GTMDBProxy1QUERY GTIDLISTGTMQUERY GTIDLISTDBProxy2QUERY GTIDLISTQUERY GTIDLISTQUERY GTIDLISTGTM子線程QUERY GTIDLISTDBProxy2QUERY GTIDLIST查詢GTID列表優(yōu)化：GTM進(jìn)行組提交GTM使用同一份活躍事務(wù)列表應(yīng)答不同Proxy發(fā)來(lái)的請(qǐng)求。

16、當(dāng)子線程沒(méi)有拼裝完返回列表時(shí)，不會(huì)處理新的請(qǐng)求。Proxy上所有的請(qǐng) 求，都需要過(guò)0.5ms才會(huì)有響應(yīng)。Proxy獲取到的事 務(wù)列表都落后 GTM 0.25ms。Proxy上所有的請(qǐng) 求，在00.5ms 內(nèi)會(huì)收到響應(yīng)。Proxy獲取到的事 務(wù)列表都落后 GTM 0.25ms。0.25msPGPG組提交優(yōu)化后對(duì)預(yù)鎖機(jī)制的影響自適應(yīng)算法，精簡(jiǎn)請(qǐng)求：依據(jù)請(qǐng)求數(shù)、累計(jì)時(shí)間和當(dāng)前負(fù)載情況，實(shí)時(shí)修改發(fā)送周期數(shù)據(jù)壓縮：通過(guò)記錄GTID起始值(8Byte)和偏移量位圖(255Byte)，數(shù)據(jù)包大小降到1K以 內(nèi)Work ThreadMem Thread收請(qǐng)求寫(xiě)增量日志寫(xiě)增量日志回響應(yīng)收請(qǐng)求回響應(yīng)Work ThreadMem Threa