云計算
近日，騰訊云發布了分布式數據庫解決方案（dcdb），其最明顯的特性之一就是提供了高于開源分布式事務xa的性能。大型業務系統有著用戶多、并發高的特點，在這方面，集中式數據庫（單機數據庫）的性能很難支持，因此主流的互聯網公司往往采用分布式（架構）數據庫，物理上利用更多的低端設備，邏輯上對大表水平拆分支撐業務的需要。
雖然分布式數據庫能解決性能難題，但事務一致性（consistency）的問題，卻很難在分布式數據庫上得到解決。
分布式事務老大難題，數據一致難以實現
眾所周知，一個事務所做的更新，分布式數據庫系統內部多個獨立的數據節點完成（每個節點的本地事務是這個全局事務的一個事務分支），在這樣一個全局事務提交期間，有可能某些事務分支無法成功提交。
針對這一問題，雖然業內早已存在理論解決方案——二階段提交協議(簡稱2pc)，并延伸出分布式事務（簡稱xa）的解決方案。但業內卻少有工程化實現且大規模應用的案例。而騰訊云分布式數據庫dcdb，卻已在內部業務中應用多年。
（圖：二階段提交算法）
目前dcdb已應用在騰訊內部90%%u4ee5上的交易、計費業務，并且三一重工（樹根互聯）、匯通天下（g7）、閱文集團（起點/創世中文網等）、微眾銀行、和泰人壽、威富通等都在該產品。
騰訊云首發分布式數據庫xa，支持mysql 5.7
騰訊云分布式數據庫dcdb，是基于騰訊金融級數據庫（公司內部代號tdsql）云化改造而來的兼容mysql協議的分布式數據庫。現如今，騰訊云dcdb已經正式在mysql 5.7(percona分支)協議上支持分布式事務xa，并已在騰訊云公有云、金融云發布供開發者使用。開發者可以通過申請dcdb實例，并在初始化后，連接實例運行如下sql進行初始化：
mysql> xa init;
query ok, 0 rows affected (0.03 sec)
注意：初始化xa前，請開啟強同步復制能力，另外該sql會創建xa.gtid_log_t，用戶在后續使用中萬勿對其進行任何操作。。
為更好的支持分布式事務，dcdb還新增了sql命令：
1) select gtid()，獲取當前分布式事務的gtid(事務的全局唯一性標識)，如果該事務不是分布式事務則返回空；
gtid的格式：
‘網關id’-‘網關隨機值’-‘序列號’-‘時間戳’-‘分區號’，例如 c46535fe-b6-dd-595db6b8-25
2) select gtid_state(“gtid”)，獲取“gtid”的狀態，可能的結果有：
a) “commit”，標識該事務已經或者最終會被提交
b) “abort”，標識該事務最終會被回滾
c) 空，由于事務的狀態會在一個小時之后清楚，因此有以下兩種可能：
1) 一個小時之后查詢，標識事務狀態已經清除
2) 一個小時以內查詢，標識事務最終會被回滾
3) 運維命令：
xa recover：向后端set發送xa recover命令，并進行匯總
xa lockwait：顯示當前分布式事務的等待關系（可以使用dot命令將輸出轉化為等待關系圖）
xa show：當前網關上正在運行的分布式事務
以python為例，可以對轉賬業務進行如下編碼：
db =
pymysql.connect(host=testhost, port=testport, user=testuser, password=testpassword,
database=testdatabase)
cursor = db.cursor()
try:
cursor.execute(begin)
#為一個賬戶bob的余額減1
query = update
t_user_balance set balance = balance – 1
where user=\\\’bob\\\’ and balance>1)
affected =
cursor.execute(query)
if affected == 0: #余額不足，回滾事務
cursor.execute(rollback)
return
#為一個賬戶john的余額加1
query = update
t_user_balance set balance = balance 1
where user=\\\’john\\\’)
cursor.execute(query)
# 為了安全起見，建議在這里執行‘select gtid()’獲取當前事務的id值，便于后續跟蹤事務的執行情況
#提交事務
cursor.execute(commit)
except pymysql.err.mysqlerror as
e:
# 發生故障，回滾事務
cursor.execute(rollback)
分布式事務的好處在于會大大降低應用開發難度，因為在某些不支持xa的數據庫中，需要業務系統通過特殊并且巧妙的設計，而非利用數據庫來解決事務中數據不一致等問題。這種對應用開發者的技術水平要求很高，越是復雜的業務系統，越會增加開發成本和技術門檻，這是業內大多數開發者面對分布式數據庫時，只能望而卻步的主要原因。
騰訊云dcdb xa關鍵實現方案
1、dcdb架構介紹
騰訊云dcdb整個集群架構簡圖如下圖，mysql采用主從節點配置（也叫作主備）一套主從節點叫做set，在每一個set外配置網關（tproxy），形成一個物理分片（shard）。
dcdb后端是mysql（或其分支版本）數據庫，目前騰訊云公有云發布支持xa的版本是基于mysql 5.7.17（percona分支）。
2、網關（tproxy）與xa
網關是用于接收請求并與后端mysql建立連接的網絡模塊。網關可以用兩種模式工作，一種稱為noshard，此模式下網關不處理/不解析sql語句，透明轉發請求和應答。另一種模式稱為shard（分布式，即支持自動水平分表）模式下，tproxy會解析sql并轉發到不同的數據分片。
在實現xa之前，網關不允許在一個事務中向多個set發送dml語句。因為未實現二階段提交（2pc）時，事務采用一階段提交，如果分布式中某一個set提交失敗了或回滾了，那么這個分布式事務就處于不一致的狀態。
（網關的工作方式）
二階段提交中需要的事務管理器（tm）。為了解決容災、簡化架構，騰訊云dcdb將tm實現在tproxy中，而dcdb的網關是一個無狀態的模塊，通過這一架構，dcdb xa可以支持：
1、分布式事務對業務透明，兼容單機事務語法(start transaction/commit/rollback/savepoint)。
2、每個網關都可以獨立接受和處理事務請求，且無需與其他網關進行協調節點故障不丟失事務。
3、允許顯式事務中多條語句分別發給多個分片。
4、網關無需持久狀態，無需容災，可以隨時經由調度集群退出或加入集群，且性能可以擴展。
5、支持autocommit下單條語句寫訪問多個分片等。
dcdb網關還允許以流式處理方式運行group by、order by，流式處理讓這類操作變得非常方式非常高效；網關還支持兩個shard使用shardkey（分表鍵）做等值連接，以及使用shardkey的子查詢。
未來，騰訊云還計劃支持分布式join、sparksql、二級分區等高級功能，兼容更多mysql高級語法。
3、強同步與xa
由于騰訊云dcdb默認采用強同步復制，即主從節點數據完全一致，因此xa事務也遵循強同步的邏輯，即需等待從機確認數據同步后，才給業務以應答（commit）。基于強同步，在以下兩種異常情況下，dcdb xa可輕松應對
1、主節點故障時，已確認事務數據不會丟失：主節點故障那么擁有最新數據和binlog的從機就被選為主節點，這其中的數據也包括所有已經向用戶確認完成提交的事務的數據。
2、原主節點恢復后重新加入集群,未確認事務自動閃回：原主節點恢復重新接入集群，它將作為從機運行，此時他可能存留多余的已提交事務（此時事務并未得到強同步同步確認，即原備機并沒有相關數據），那么這些事務會被閃回。雖然這些事務可能已經在原主節點的mysql內部完成提交，但由于強同步機制，他并不會向客戶端返回commit語句，這意味著仍被視為一個未完成的事務。因此，這些事務的閃回了也并沒有破壞數據庫的acid屬性。這里值得說的是，閃回flashback是基于binlog生成做逆操作，它與數據庫回滾并不同rollback，閃回可以做ddl操作。
騰訊云dcdb的強同步為騰訊金融級數據庫自研的一項能力，性能比官方半同步大幅提高，幾乎等于異步復制性能，騰訊云dcdb在騰訊內部應用多年，未發生過一起因為主從切換、故障帶來的數據誤差。而且

云服務器是怎么收取費用的
在電腦中如何刪除殘留的dll文件
連接mysql報1045錯誤怎么辦
如何申請郵箱免費注冊郵箱
到期域名如何才能注冊成功
百度云服務器微端更新怎么設置
騰訊云服務器建站教程1
對象存儲哪個好