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

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

2、商用 千萬套單板商用17年厚積薄發(fā)100%代碼掌控100+發(fā)明專利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ù)庫總體架構(gòu)實(shí)時一致的 分布式事務(wù)控制同城異地災(zāi)備 一致的備份恢復(fù)線性橫向擴(kuò)展 聯(lián)機(jī)數(shù)據(jù)重分布豐富的監(jiān)控體系 完善的運(yùn)維能力GoldenDB數(shù)據(jù)庫滿足金融核心的關(guān)鍵要求AgendaGoldenDB

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

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

5、交時間有空隙，若此時事務(wù)T2讀取2個賬戶的余額，會發(fā)現(xiàn)余額之和是50+100=150。存在事務(wù)T1對賬戶1上扣錢成功，給賬戶2加錢失敗的情況。賬戶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)會等待消息，需

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

7、 Confirm Cancel數(shù)據(jù)節(jié)點(diǎn)2從 業(yè) 務(wù)從 業(yè) 務(wù)通過業(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基于樂觀鎖的分布式一階段提交輔助自動補(bǔ)償機(jī)制: 一階段提交 自動補(bǔ)償回滾優(yōu)點(diǎn)： 應(yīng)用層無需實(shí)現(xiàn)補(bǔ)償邏輯。 失敗回滾是少數(shù)情況，整體性能高于兩階段提交。GoldenDB事務(wù)原子性實(shí)現(xiàn)機(jī)制通過回 滾進(jìn)行 事務(wù)補(bǔ) 償定位遍歷生成執(zhí)行提升回 滾性能表定義 緩存預(yù)分析 并行查找

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

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

10、性。關(guān)鍵說明： 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ù)提交的的時候才釋放讀鎖和寫鎖GTM封鎖：事務(wù)提交之前，所有的GTID相關(guān)的數(shù)據(jù)都不能被讀取和修改活躍事務(wù)列表里的GTID，相當(dāng)于寫鎖。-保障了寫寫和寫讀沖突下的數(shù)據(jù)一致性。通過對讀操作顯式加鎖，達(dá)到嚴(yán)格的SS2PL效果。-保障了讀寫沖突下的數(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ī)制寫一致性處理滿足條件的記錄上無鎖滿足條件的記錄上有鎖GTID不活躍GTID活躍事務(wù)處理總結(jié)讀一致性處理臟讀讀已提交有排它鎖無排它鎖GTID不活躍GTID活躍可重復(fù)讀有排它鎖無排它鎖可序列化加共享鎖無沖突加共享鎖有沖突GTID不活躍GTID活躍GTID不活躍GTID活躍事務(wù)處理總結(jié)AgendaGoldenDB 數(shù)據(jù)庫架構(gòu)GoldenDB 事

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

14、TID2release GTID3release GTID4 release GTID10申請/釋放GTID優(yōu)化：Proxy批量請求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線程的請求，使用一份活躍事務(wù)列表應(yīng)答。當(dāng)在途請求沒有返回時，代理線程不會發(fā)送新的查詢請求。DBProxy1GTMDBProxy1QUERY GTIDLISTGTMQUERY GTIDLISTDBProxy2QUERY GTIDLISTQUERY GTIDLISTQUERY GTIDLISTGTM子線程QUERY GTIDLISTDBProxy2QUERY GTIDLIST查詢GTID列表優(yōu)化：GTM進(jìn)行組提交GTM使用同一份活躍事務(wù)列表應(yīng)答不同Proxy發(fā)來的請求。

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