如何解決分布式事務(wù)XA一致性問題
如何解決分布式事務(wù)XA一致性問題，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。
公司主營(yíng)業(yè)務(wù)：網(wǎng)站制作、成都網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)公司推出綿陽免費(fèi)做網(wǎng)站回饋大家。
大型業(yè)務(wù)系統(tǒng)有著用戶多、并發(fā)高的特點(diǎn)，在這方面，集中式數(shù)據(jù)庫（單機(jī)數(shù)據(jù)庫）的性能很難支持，因此主流的互聯(lián)網(wǎng)公司往往采用分布式（架構(gòu)）數(shù)據(jù)庫，物理上利用更多的低端設(shè)備，邏輯上對(duì)大表水平拆分支撐業(yè)務(wù)的需要。
雖然分布式數(shù)據(jù)庫能解決性能難題，但事務(wù)一致性（Consistency）的問題，卻很難在分布式數(shù)據(jù)庫上得到解決。
分布式事務(wù)老大難題
數(shù)據(jù)一致難以實(shí)現(xiàn)
眾所周知，一個(gè)事務(wù)所做的更新，分布式數(shù)據(jù)庫系統(tǒng)內(nèi)部多個(gè)獨(dú)立的數(shù)據(jù)節(jié)點(diǎn)完成（每個(gè)節(jié)點(diǎn)的本地事務(wù)是這個(gè)全局事務(wù)的一個(gè)事務(wù)分支），在這樣一個(gè)全局事務(wù)提交期間，有可能某些事務(wù)分支無法成功提交。
針對(duì)這一問題，雖然業(yè)內(nèi)早已存在理論解決方案——二階段提交協(xié)議(簡(jiǎn)稱2PC)，并延伸出分布式事務(wù)（簡(jiǎn)稱XA）的解決方案。但業(yè)內(nèi)卻少有工程化實(shí)現(xiàn)且大規(guī)模應(yīng)用的案例。而騰訊云分布式數(shù)據(jù)庫DCDB，卻已在內(nèi)部業(yè)務(wù)中應(yīng)用多年。
（圖：二階段提交算法）
目前DCDB已應(yīng)用在騰訊內(nèi)部90%以上的交易、計(jì)費(fèi)業(yè)務(wù)，并且三一重工（樹根互聯(lián)）、匯通天下（G7）、閱文集團(tuán)（起點(diǎn)/創(chuàng)世中文網(wǎng)等）、微眾銀行、和泰人壽、威富通等都在該產(chǎn)品。
騰訊云首發(fā)分布式數(shù)據(jù)庫XA
支持MySQL 5.7
騰訊云分布式數(shù)據(jù)庫DCDB，是基于騰訊金融級(jí)數(shù)據(jù)庫（公司內(nèi)部代號(hào)TDSQL）云化改造而來的兼容MySQL協(xié)議的分布式數(shù)據(jù)庫?，F(xiàn)如今，騰訊云DCDB已經(jīng)正式在MySQL 5.7(percona分支)協(xié)議上支持分布式事務(wù)XA，并已在騰訊云公有云、金融云發(fā)布供開發(fā)者使用。開發(fā)者可以通過申請(qǐng)DCDB實(shí)例，并在初始化后，連接實(shí)例運(yùn)行如下sql進(jìn)行初始化：
MySQL> xa init;
Query OK, 0 rows affected (0.03 sec)
注意：初始化xa前，請(qǐng)開啟強(qiáng)同步復(fù)制能力，另外該sql會(huì)創(chuàng)建xa.gtid_log_t，用戶在后續(xù)使用中萬勿對(duì)其進(jìn)行任何操作。
為更好的支持分布式事務(wù)，DCDB還新增了SQL命令：
1)SELECT gtid()，獲取當(dāng)前分布式事務(wù)的gtid(事務(wù)的全局唯一性標(biāo)識(shí))，如果該事務(wù)不是分布式事務(wù)則返回空；
gtid的格式：
‘網(wǎng)關(guān)id’-‘網(wǎng)關(guān)隨機(jī)值’-‘序列號(hào)’-‘時(shí)間戳’-‘分區(qū)號(hào)’，例如 c46535fe-b6-dd-595db6b8-252)SELECT gtid_state(“gtid”)，獲取“gtid”的狀態(tài)，可能的結(jié)果有：
a)“COMMIT”，標(biāo)識(shí)該事務(wù)已經(jīng)或者最終會(huì)被提交
b)“ABORT”，標(biāo)識(shí)該事務(wù)最終會(huì)被回滾
c) 空，由于事務(wù)的狀態(tài)會(huì)在一個(gè)小時(shí)之后清楚，因此有以下兩種可能：
1) 一個(gè)小時(shí)之后查詢，標(biāo)識(shí)事務(wù)狀態(tài)已經(jīng)清除
2) 一個(gè)小時(shí)以內(nèi)查詢，標(biāo)識(shí)事務(wù)最終會(huì)被回滾3) 運(yùn)維命令：
xa recover：向后端SET發(fā)送xa recover命令，并進(jìn)行匯總
xa lockwait：顯示當(dāng)前分布式事務(wù)的等待關(guān)系（可以使用dot命令將輸出轉(zhuǎn)化為等待關(guān)系圖）
xa show：當(dāng)前網(wǎng)關(guān)上正在運(yùn)行的分布式事務(wù)
以Python為例，可以對(duì)轉(zhuǎn)賬業(yè)務(wù)進(jìn)行如下編碼：
db = pyMySQL.connect(host=testHost,
port=testPort, user=testUser, password=testPassword, database=testDatabase)
cursor = db.cursor()
try:
cursor.execute("begin")
#為一個(gè)賬戶Bob的余額減1
query = "update t_user_balance SET balance = balance - 1 where user='Bob' and balance>1)
affected = cursor.execute(query)
if affected == 0: #余額不足，回滾事務(wù)
cursor.execute("rollback")
return
#為一個(gè)賬戶John的余額加1
query = "update t_user_balance SET balance = balance + 1 where user='John')
cursor.execute(query)
#為了安全起見，建議在這里執(zhí)行‘SELECT gtid()’獲取當(dāng)前事務(wù)的id值，便于后續(xù)跟蹤事務(wù)的執(zhí)行情況
#提交事務(wù)
cursor.execute("commit")
except pyMySQL.err.MySQLError as e:
#發(fā)生故障，回滾事務(wù)
cursor.execute("rollback")分布式事務(wù)的好處在于會(huì)大大降低應(yīng)用開發(fā)難度，因?yàn)樵谀承┎恢С諼A的數(shù)據(jù)庫中，需要業(yè)務(wù)系統(tǒng)通過特殊并且巧妙的設(shè)計(jì)，而非利用數(shù)據(jù)庫來解決事務(wù)中數(shù)據(jù)不一致等問題。這種對(duì)應(yīng)用開發(fā)者的技術(shù)水平要求很高，越是復(fù)雜的業(yè)務(wù)系統(tǒng)，越會(huì)增加開發(fā)成本和技術(shù)門檻，這是業(yè)內(nèi)大多數(shù)開發(fā)者面對(duì)分布式數(shù)據(jù)庫時(shí)，只能望而卻步的主要原因。
騰訊云DCDB XA關(guān)鍵實(shí)現(xiàn)方案
1、DCDB架構(gòu)介紹
騰訊云DCDB整個(gè)集群架構(gòu)簡(jiǎn)圖如下圖，MySQL采用主從節(jié)點(diǎn)配置（也叫作主備）一套主從節(jié)點(diǎn)叫做SET，在每一個(gè)SET外配置網(wǎng)關(guān)（TProxy），形成一個(gè)物理分片（Shard）。
（網(wǎng)關(guān)的工作方式）
二階段提交中需要的事務(wù)管理器（TM）。為了解決容災(zāi)、簡(jiǎn)化架構(gòu)，騰訊云DCDB將TM實(shí)現(xiàn)在TProxy中，而DCDB的網(wǎng)關(guān)是一個(gè)無狀態(tài)的模塊，通過這一架構(gòu)，DCDB XA可以支持：
（1）、分布式事務(wù)對(duì)業(yè)務(wù)透明，兼容單機(jī)事務(wù)語法(start transaction/commit/rollback/savepoint)；
（2）、每個(gè)網(wǎng)關(guān)都可以獨(dú)立接受和處理事務(wù)請(qǐng)求，且無需與其他網(wǎng)關(guān)進(jìn)行協(xié)調(diào)節(jié)點(diǎn)故障不丟失事務(wù)；
（3）、允許顯式事務(wù)中多條語句分別發(fā)給多個(gè)分片；
（4）、網(wǎng)關(guān)無需持久狀態(tài)，無需容災(zāi)，可以隨時(shí)經(jīng)由調(diào)度集群退出或加入集群，且性能可以擴(kuò)展；
（5）、支持autocommit下單條語句寫訪問多個(gè)分片等。
DCDB網(wǎng)關(guān)還允許以流式處理方式運(yùn)行g(shù)roup by、order by，流式處理讓這類操作變得非常方式非常高效；網(wǎng)關(guān)還支持兩個(gè)Shard使用shardkey（分表鍵）做等值連接，以及使用shardkey的子查詢。
未來，騰訊云還計(jì)劃支持分布式JOIN、Sparksql、二級(jí)分區(qū)等高級(jí)功能，兼容更多MySQL高級(jí)語法。
3、強(qiáng)同步與XA
由于騰訊云DCDB默認(rèn)采用強(qiáng)同步復(fù)制，即主從節(jié)點(diǎn)數(shù)據(jù)完全一致，因此XA事務(wù)也遵循強(qiáng)同步的邏輯，即需等待從機(jī)確認(rèn)數(shù)據(jù)同步后，才給業(yè)務(wù)以應(yīng)答（commit）?；趶?qiáng)同步，在以下兩種異常情況下，DCDB XA可輕松應(yīng)對(duì)。
（1）、主節(jié)點(diǎn)故障時(shí)，已確認(rèn)事務(wù)數(shù)據(jù)不會(huì)丟失：主節(jié)點(diǎn)故障那么擁有最新數(shù)據(jù)和binlog的從機(jī)就被選為主節(jié)點(diǎn)，這其中的數(shù)據(jù)也包括所有已經(jīng)向用戶確認(rèn)完成提交的事務(wù)的數(shù)據(jù)。
（2）、原主節(jié)點(diǎn)恢復(fù)后重新加入集群,未確認(rèn)事務(wù)自動(dòng)閃回：原主節(jié)點(diǎn)恢復(fù)重新接入集群，它將作為從機(jī)運(yùn)行，此時(shí)他可能存留多余的已提交事務(wù)（此時(shí)事務(wù)并未得到強(qiáng)同步同步確認(rèn)，即原備機(jī)并沒有相關(guān)數(shù)據(jù)），那么這些事務(wù)會(huì)被閃回。雖然這些事務(wù)可能已經(jīng)在原主節(jié)點(diǎn)的MySQL內(nèi)部完成提交，但由于強(qiáng)同步機(jī)制，他并不會(huì)向客戶端返回commit語句，這意味著仍被視為一個(gè)未完成的事務(wù)。因此，這些事務(wù)的閃回了也并沒有破壞數(shù)據(jù)庫的ACID屬性。這里值得說的是，閃回flashback是基于binlog生成做逆操作，它與數(shù)據(jù)庫回滾并不同rollback，閃回可以做DDL操作。
騰訊云DCDB的強(qiáng)同步為騰訊金融級(jí)數(shù)據(jù)庫自研的一項(xiàng)能力，性能比官方半同步大幅提高，幾乎等于異步復(fù)制性能，騰訊云DCDB在騰訊內(nèi)部應(yīng)用多年，未發(fā)生過一起因?yàn)橹鲝那袚Q、故障帶來的數(shù)據(jù)誤差。而且，從性能上，也撐住了騰訊公司各類大型運(yùn)營(yíng)活動(dòng)如紅包、各類游戲大型推廣等海量并發(fā)，其主要原因是強(qiáng)同步采用異步提交/等待方式，且不占用數(shù)據(jù)庫工作線程。
4、并發(fā)控制與隔離級(jí)別
為了達(dá)到數(shù)據(jù)一致性和性能的平衡，分布式事務(wù)的關(guān)鍵是數(shù)據(jù)庫隔離控制。XA的隔離級(jí)別最高可以達(dá)到serializable（完全串行化），該級(jí)別將不存在幻讀的問題，serializable級(jí)別可以通過設(shè)置SET global tx_isolation='serializable'來對(duì)DCDB所有物理分片（和其上承載的MySQL數(shù)據(jù)庫）進(jìn)行設(shè)置。當(dāng)然，也可以通過調(diào)整隔離級(jí)別以調(diào)整數(shù)據(jù)庫實(shí)例性能，理論上，Read Uncommitted性能最高，但可能存在臟讀、幻讀的情況。
(1)、網(wǎng)關(guān)在執(zhí)行一個(gè)事務(wù)的insert/update/delete語句時(shí)，會(huì)記錄這個(gè)語句修改了哪個(gè)SET；
(2)、SET時(shí)會(huì)發(fā)送一個(gè)XA START在這個(gè)SET上面啟動(dòng)事務(wù)分支；（注：XA事務(wù)開始時(shí)，并不確認(rèn)事務(wù)將以哪種提交方式執(zhí)行，因此總是以xa start來開啟一個(gè)事務(wù)）；
(3)、檢測(cè)是否影響SET個(gè)數(shù)≤1，若是，則直接做一階段提交（xa commit one phase）。
(4)、影響SET個(gè)數(shù)≥2，則改為做兩階段提交：
1)網(wǎng)關(guān)首先發(fā)送xa prepare‘gtid’ 給參與的SET（大于等于2個(gè)SET）；
2)SET接受到xa prepare應(yīng)答ok(表示成功確認(rèn))；
3)收到成功確認(rèn)后，寫入XA對(duì)應(yīng)的commit log，再發(fā)送xa commit‘gtid’參與SET；
4)如果有SET返回了錯(cuò)誤，或者寫入commit log失敗，那么網(wǎng)關(guān)發(fā)送 xa rollback‘gtid’給相關(guān)SET，這樣這個(gè)全局事務(wù)就實(shí)現(xiàn)了回滾。
騰訊云DCDB的commit log是在SET中存儲(chǔ)，這個(gè)步驟是批量完成的——網(wǎng)關(guān)后臺(tái)線程會(huì)匯集正在提交的分布式事務(wù)然后在獨(dú)立的連接和事務(wù)中完成對(duì)每個(gè)SET的寫入，并且每個(gè)事務(wù)的commit log只寫入一個(gè)SET中，因而這個(gè)開銷并沒有顯著增加事務(wù)的提交耗時(shí)或者降低TPS。而且，依賴騰訊云DCDB已有的強(qiáng)同步和容災(zāi)特性，只要XA成功寫入了commit log，就意味著數(shù)據(jù)已經(jīng)寫入從機(jī)。
雖然絕大多數(shù)的XA事務(wù)可以正常執(zhí)行。但極少數(shù)的異常情況還是會(huì)影響整個(gè)集群穩(wěn)定性，因此，騰訊云設(shè)計(jì)了agent（監(jiān)控模塊），在故障后繼續(xù)協(xié)助完成本地MySQL上面prepared事務(wù)的提交，即agent會(huì)解析commit log，并根據(jù)異常處理本地仍然處于prepared的事務(wù)數(shù)據(jù)；如果commit log上面沒有事務(wù)的提交決定的話，agent也會(huì)回滾超時(shí)未被提交的prepared本地事務(wù)。
雖然在MySQL 5.5、5.6等版本早已實(shí)現(xiàn)XA，但這兩個(gè)版本相對(duì)于5.7仍然有性能不足，因此騰訊云目前只在公有云上基于5.7.17支持XA版本。如今，騰訊云在MySQL 、percona、MariaDB等分支中做了大量?jī)?yōu)化和相關(guān)bug修復(fù)（部分已經(jīng)提交到社區(qū)修復(fù)patch或開源），未來騰訊云還將繼續(xù)致力于新特性的開發(fā)和相關(guān)Bug的修復(fù)，為眾多有需要的企業(yè)，提供更好的分布式數(shù)據(jù)庫支持。
看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。
新聞標(biāo)題：如何解決分布式事務(wù)XA一致性問題
當(dāng)前URL：http://m.jiaotiyi.com/article/ppsgoi.html