關(guān)于數(shù)據(jù)庫的使用，在京東有幾個(gè)趨勢，早期在京東主要用SqlServer及Oracle也有少量采用MySQL，隨著業(yè)務(wù)發(fā)展技術(shù)積累及使用成本等因素，很多業(yè)務(wù)都開始使用MySQL，包括早期使用SqlServer及Oracle的很多核心業(yè)務(wù)也都漸漸的開始遷移到MySQL，單機(jī)的MySQL往往無法支撐這類業(yè)務(wù)，需要考分布式的解決方案，另外原本使用MySQL的業(yè)務(wù)隨著數(shù)據(jù)量及訪問量的增加也會(huì)遇到瓶頸最終也會(huì)考慮采用分布式解決的方案，整個(gè)京東發(fā)展趨勢如圖1所示。

圖1 業(yè)務(wù)使用數(shù)據(jù)庫演變趨勢

分布式的數(shù)據(jù)庫解決方案有很多種，在各個(gè)互聯(lián)網(wǎng)公司使用得也是非常的普遍，本質(zhì)上就是將數(shù)據(jù)拆開存儲(chǔ)在多個(gè)節(jié)點(diǎn)上從而緩解單節(jié)點(diǎn)的壓力，業(yè)務(wù)層面也可以根據(jù)業(yè)務(wù)特點(diǎn)自行進(jìn)行拆分，如圖2所示，假設(shè)有一張user表，以ID為拆分鍵，假設(shè)拆分成兩份，最簡單的就是奇數(shù)ID的數(shù)據(jù)落到一個(gè)存儲(chǔ)節(jié)點(diǎn)上，偶數(shù)ID的數(shù)據(jù)落到另外一個(gè)存儲(chǔ)節(jié)點(diǎn)上，實(shí)際部署示意圖如圖3所示。

除了業(yè)務(wù)層面做拆分，也可以考慮采用較為通用的一些解決方案，主要分為兩類，一類是客戶端解決方案，這種方案是在業(yè)務(wù)應(yīng)用中引入特定的客戶端包，通過該客戶端包完成數(shù)據(jù)的拆分查詢及結(jié)果匯總等操作，這種方案對業(yè)務(wù)有一定侵入性，隨著業(yè)務(wù)應(yīng)用實(shí)例部署的數(shù)量比較大，數(shù)據(jù)庫端可能會(huì)面臨連接數(shù)壓力比較大的問題，另外版本升級也比較困難，優(yōu)點(diǎn)是鏈路較短，從應(yīng)用實(shí)例直接到數(shù)據(jù)庫。

圖2 數(shù)據(jù)拆分示意圖

另一類是中間件的解決方案，這種方案是提供兼容數(shù)據(jù)庫傳輸協(xié)議及語法規(guī)范的代理，業(yè)務(wù)在連接中間件的時(shí)候可以直接使用傳統(tǒng)的JDBC等客戶端，從而大大減輕了業(yè)務(wù)開發(fā)層面的負(fù)擔(dān)，弊端是中間件的開發(fā)難度會(huì)比客戶端方案稍微高一點(diǎn)，另外網(wǎng)絡(luò)傳輸鏈路上多走了一段，理論上對性能略有影響，實(shí)際使用環(huán)境中這些系統(tǒng)都是在機(jī)房內(nèi)網(wǎng)訪問，這種網(wǎng)絡(luò)上的影響完全可以忽略不計(jì)。

圖3 系統(tǒng)部署示意圖

根據(jù)上述分析，為了更好的支撐京東大量的大規(guī)模數(shù)據(jù)量的業(yè)務(wù)，我們開發(fā)了一套兼容MySQL協(xié)議的分布式數(shù)據(jù)庫的中間件解決方案，我們稱之為JProxy，這套方案經(jīng)過了多次的演變最終完成并支撐了京東全集團(tuán)的去Oracle/Sqlserver任務(wù)。

JProxy第一個(gè)版本如圖4所示，每個(gè)JProxy都會(huì)有一個(gè)配置文件，我們會(huì)在配置文件中配置相應(yīng)業(yè)務(wù)的庫表拆分信息及路由信息， JProxy接收到SQL以后會(huì)對SQL進(jìn)行解析再根據(jù)路由信息決定SQL是否需要重寫及該發(fā)往哪些節(jié)點(diǎn)，等各節(jié)點(diǎn)結(jié)果返回以后再將結(jié)果匯總按照MySQL傳輸協(xié)議返回給應(yīng)用。

結(jié)合上文的例子，當(dāng)用戶查詢user這張表時(shí)假設(shè)SQL語句是select * from user where id = 1 or id = 2，當(dāng)收到這條SQL以后，JProxy會(huì)將SQL拆分為select * from user where id=1 及select * from user where id = 2， 再分別把這兩條sql語句發(fā)往后端的節(jié)點(diǎn)上，最后將兩個(gè)節(jié)點(diǎn)上獲取到的兩條記錄一并返回給應(yīng)用。

這種方案在業(yè)務(wù)庫表比較少的時(shí)候是可行的，隨著業(yè)務(wù)的發(fā)展庫表的數(shù)量可能會(huì)不斷增加，尤其是針對去Oracle的業(yè)務(wù)在切換數(shù)據(jù)庫的時(shí)候可能是一次切換幾張表，下一次再切換另外幾張表，這就要求經(jīng)常修改配置文件。另外JProxy在部署的時(shí)候至少需要部署兩份甚至多份，如圖5所示，此時(shí)面臨一個(gè)問題是如何保證所有的配置文件在不斷修改的過程中是完全一致的。在早期運(yùn)維過程中，我們靠人工修改完一份配置文件，再將相應(yīng)的配置文件拷貝給其他的JProxy，確保JProxy配置文件內(nèi)容一致，這個(gè)過程心智負(fù)擔(dān)較重且容易出錯(cuò)。

圖4 版本一

圖5 配置文件

在之后的版本中我們引入了JManager模塊，這個(gè)模塊負(fù)責(zé)的工作是管理配置文件中的路由元信息，如圖6所示。JProxy的路由元信息都是通過JManager來統(tǒng)一獲取，我們只需要通過JManager往元數(shù)據(jù)庫里添加修改路由元數(shù)據(jù)，操作完成以后通知各個(gè)JProxy動(dòng)態(tài)加載路由信息就可以保證每個(gè)JProxy的路由信息是完全一致的，從而解決維護(hù)路由元信息一致性的痛點(diǎn)。

圖6 版本二

在提到分布式數(shù)據(jù)庫解決方案時(shí)一定會(huì)考慮的一個(gè)問題是擴(kuò)容問題，擴(kuò)容有兩種方式，一種我們稱之為re-sharding方案，簡單的說就是一片拆兩片，兩片拆為四片，如圖7所示，原本只有一個(gè)MySQL實(shí)例一個(gè)shard，之后拆分成shard1和shard2兩個(gè)分片，之后再添加新的MySQL實(shí)例，將shard1拆分成shard11和shard12兩個(gè)分片，將shard2拆分成shard21和shard22兩個(gè)分片放到另外新加的MySQL實(shí)例上，這種擴(kuò)容方式是最理想的，但具體實(shí)現(xiàn)的時(shí)候會(huì)略微麻煩一點(diǎn)，我們短期之內(nèi)選擇了另一種偏保守一點(diǎn)在合理預(yù)估前提下足以支撐業(yè)務(wù)發(fā)展的擴(kuò)容模式，我們稱之為pre-sharding方案，這種方案是預(yù)先拆分在一定時(shí)期內(nèi)足夠用的分片數(shù)，在前期數(shù)據(jù)量較少時(shí)這些分片可以放在一個(gè)或少量的幾個(gè)MySQL實(shí)例上，等后期數(shù)據(jù)量增大以后可以往集群中加新的MySQL實(shí)例，將原本的分片遷移到新添加的MySQL實(shí)例上，如圖8所示，我們在一開始就拆分成了shard1、shard2、shard3、shard4四個(gè)分片，這四個(gè)分片最初是在一個(gè)MySQL實(shí)例上，數(shù)據(jù)量增大以后我們可以添加新的MySQL實(shí)例，將shard3和shard4遷移新的MySQL實(shí)例上，整個(gè)集群分片數(shù)沒有發(fā)生變化但是容量已經(jīng)變成了原來的兩倍。

圖7 re-sharding方案

圖8 pre-sharding方案

Pre-sharding方案相當(dāng)于通過遷移完成達(dá)到擴(kuò)容的目的，分片位置的變動(dòng)涉及到數(shù)據(jù)的遷移驗(yàn)證及路由元數(shù)據(jù)的變更等一系列變動(dòng)，所以我們引入了JTransfer系統(tǒng)，如圖9所示。JTransfer可以做到在線無縫遷移，遷移擴(kuò)容時(shí)只需提交一條遷移計(jì)劃，指定將某個(gè)分片從哪個(gè)源實(shí)例遷移到哪個(gè)目標(biāo)實(shí)例，可以指定在何時(shí)開始遷移任務(wù)，等到了時(shí)間點(diǎn)系統(tǒng)會(huì)自動(dòng)開始做遷移。整個(gè)遷移過程中涉及到遷移基礎(chǔ)全量數(shù)據(jù)和遷移過程中業(yè)務(wù)訪問產(chǎn)生的增量數(shù)據(jù)，一開始會(huì)將基礎(chǔ)全量數(shù)據(jù)從源實(shí)例中dump出來到目標(biāo)實(shí)例恢復(fù)，確認(rèn)數(shù)據(jù)正確以后開始追趕增量數(shù)據(jù)，當(dāng)增量數(shù)據(jù)追趕到一定程度系統(tǒng)預(yù)估可以快速追趕結(jié)束時(shí)，我們會(huì)做一個(gè)短暫的鎖定操作，從而確保將最后的增量全部追趕完成，這個(gè)鎖定時(shí)間也是在提交遷移任務(wù)時(shí)可以指定的一個(gè)參數(shù)，比如最多只能鎖定20s，如果因?yàn)榇藭r(shí)訪問量突然增大等原因最終剩余的增量沒能在20s內(nèi)追趕完成，整個(gè)遷移任務(wù)將會(huì)放棄，確保對線上訪問影響達(dá)到最小。遷移完成之后會(huì)將路由元信息進(jìn)行修改，同時(shí)將路由元信息推送給所有的JProxy，最后再解除鎖定，訪問將根據(jù)路由打到分片所在的新位置。

圖9 版本三

系統(tǒng)在生產(chǎn)環(huán)境中使用的時(shí)候，除了考慮以上的介紹以外還需要考慮很多部署及運(yùn)維的事情，首先要考慮的就是系統(tǒng)如何活下來，需要考慮系統(tǒng)的自我保護(hù)能力，要確保系統(tǒng)的穩(wěn)定性，要做到性能能夠滿足業(yè)務(wù)需求。

在JProxy內(nèi)部我們采用了基于事件驅(qū)動(dòng)的網(wǎng)絡(luò)IO模型同時(shí)考慮到多核等特點(diǎn)，將整個(gè)系統(tǒng)的性能發(fā)揮到極致，在壓測時(shí)JProxy表現(xiàn)出來的性能隨著MySQL實(shí)例的增加幾乎是呈現(xiàn)線性增長的趨勢，而且整個(gè)過程中JProxy所在機(jī)器毫無壓力。

保證性能還不夠，還需要考慮控制連接數(shù)、控制系統(tǒng)內(nèi)存等，連接數(shù)主要是控制連接的數(shù)量這個(gè)比較好理解，控制內(nèi)存主要是指控制系統(tǒng)在使用過程中對內(nèi)存的需求量，比如在做數(shù)據(jù)抽數(shù)時(shí)候，sql語句是類似select * from table這種的全量查詢，此時(shí)后端所有的MySQL數(shù)據(jù)會(huì)通過多條連接并發(fā)地往中間件發(fā)送數(shù)據(jù)，從中間件到應(yīng)用只有一條連接，如果不對內(nèi)存進(jìn)行控制就會(huì)造成中間件OOM，在具體實(shí)現(xiàn)的時(shí)候我們通過將數(shù)據(jù)壓在TCP棧中來控制中間件前后端連接的網(wǎng)絡(luò)流速從而很好的保證了整個(gè)系統(tǒng)的內(nèi)存是在可控范圍內(nèi)。

另外還需要考慮權(quán)限，哪些IP可以訪問哪些IP不能訪問都需要可以精確的控制，具體到某一張表還需要控制增刪改查的權(quán)限，我們建議業(yè)務(wù)在寫SQL的時(shí)候盡量都帶有拆分字段保證SQL都可以落在某個(gè)分片上從而保證整個(gè)訪問是足夠的簡單可控，我們?yōu)橹峁┝司?xì)的權(quán)限控制，可以做到表級別的增刪改查權(quán)限，包括是否要帶有拆分字段，最大程度做到對SQL的控制，保證業(yè)務(wù)在測試階段寫出不滿足期望的SQL都能及時(shí)發(fā)現(xiàn)，大大降低后期線上運(yùn)行時(shí)的風(fēng)險(xiǎn)。

除了基本的穩(wěn)定性之外，在整個(gè)系統(tǒng)全局上還需要考慮到服務(wù)高可用方案。JProxy是無狀態(tài)的，一個(gè)業(yè)務(wù)在同一個(gè)機(jī)房內(nèi)部署至少兩個(gè)JProxy且必須跨機(jī)架的，保證在同一個(gè)機(jī)房里JProxy是高可用的。在另外的機(jī)房會(huì)部署再部署兩個(gè)JProxy，做到跨機(jī)房的高可用。除了中間件自身的高可用以外還需要保證數(shù)據(jù)庫層面的高可用，全鏈路的高可用才是真正的高可用。數(shù)據(jù)庫層面在同一個(gè)機(jī)房里會(huì)按照一主一從部署，在備用機(jī)房會(huì)再部署一個(gè)備，如圖10所示。JProxy訪問MySQL時(shí)通過域名訪問，如果MySQL的主出異常數(shù)據(jù)庫會(huì)進(jìn)行相應(yīng)的主從切換操作，JProxy可以訪問到切換以后新的主，如果整個(gè)機(jī)房的數(shù)據(jù)庫異常可以直接將數(shù)據(jù)的域名切換到備用機(jī)房，保證JProxy可以訪問到備用機(jī)房的數(shù)據(jù)庫。業(yè)務(wù)訪問JProxy時(shí)也是通過域名訪問，如果一個(gè)機(jī)房的JProxy都出現(xiàn)了異常，和數(shù)據(jù)庫類似直接將JProxy前端的域名切換到備用機(jī)房，從而保證業(yè)務(wù)始終都能正常訪問JProxy。

數(shù)據(jù)高可靠也是非常關(guān)鍵的點(diǎn)，我們會(huì)這對數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行定期備份，將備份數(shù)據(jù)存儲(chǔ)到相應(yīng)的存儲(chǔ)系統(tǒng)中，從而保證數(shù)據(jù)庫中的數(shù)據(jù)即使被刪除依然是可以恢復(fù)的。

圖10 部署示意圖

系統(tǒng)在線上運(yùn)行時(shí)候監(jiān)控報(bào)警是極其重要的，監(jiān)控可以分多個(gè)層次，如圖11所示，從主機(jī)和操作系統(tǒng)的信息到應(yīng)用系統(tǒng)的信息到特定系統(tǒng)內(nèi)部特定的信息的監(jiān)控等，針對操作系統(tǒng)及主機(jī)的監(jiān)控京東有MJDOS系統(tǒng)可以把系統(tǒng)的內(nèi)存/cpu/磁/網(wǎng)卡/機(jī)器負(fù)載等各種信息都納入監(jiān)控系統(tǒng)，這些操作系統(tǒng)的基礎(chǔ)信息對系統(tǒng)異常的診斷非常關(guān)鍵，比如因?yàn)榫W(wǎng)絡(luò)丟包等引起的服務(wù)異常都可以在這個(gè)監(jiān)控系統(tǒng)中及時(shí)找到根源。

京東還有統(tǒng)一的監(jiān)控報(bào)警系統(tǒng)UMP，這個(gè)監(jiān)控系統(tǒng)主要是給所有的應(yīng)用系統(tǒng)服務(wù)，所有的應(yīng)用系統(tǒng)按照一定的規(guī)則暴露接口，在UMP系統(tǒng)中注冊以后，UMP系統(tǒng)就可以提供一整套監(jiān)控報(bào)警服務(wù)，最基本的比如系統(tǒng)的存活監(jiān)控以及是否有慢查詢等。

除了這兩個(gè)基本的監(jiān)控系統(tǒng)以外，我們還針對整套中間件系統(tǒng)開發(fā)了定制的監(jiān)控系統(tǒng)JMonitor，之所以開發(fā)這套監(jiān)控系統(tǒng)是因?yàn)槲覀冃枰杉嗟亩ㄖ频谋O(jiān)控信息，在系統(tǒng)發(fā)生異常時(shí)能夠第一時(shí)間定位問題，舉個(gè)例子當(dāng)業(yè)務(wù)發(fā)現(xiàn)TP99下降時(shí)往往伴隨著有慢SQL，應(yīng)用從發(fā)送SQL到收到結(jié)果這個(gè)過程中經(jīng)過了JProxy到MySQL又從MySQL經(jīng)過JProxy再回到應(yīng)用，這條鏈路上任何一個(gè)環(huán)節(jié)都可能慢，不管是哪個(gè)階段耗時(shí)，我們需要將這種慢SQL的記錄精細(xì)化，精細(xì)到各個(gè)階段都花了多少時(shí)間，做到出現(xiàn)慢SQL時(shí)能快速準(zhǔn)確的找到問題根源快速解決問題。

另外在配合業(yè)務(wù)去Oracle/SqlServer時(shí)，我們不建議使用跨庫的事務(wù)，但是會(huì)出現(xiàn)有一種情況，同一個(gè)事務(wù)里的SQL都是帶有拆分字段的，每條SQL都是單節(jié)點(diǎn)的，同一個(gè)事務(wù)里有多條這種SQL，結(jié)果卻出現(xiàn)這個(gè)事務(wù)是跨庫的，這種事務(wù)我們都會(huì)有詳細(xì)的記錄，業(yè)務(wù)方可以直接通過JMonitor找到這種事務(wù)從而更好的進(jìn)一步改進(jìn)。除了這個(gè)以外，在測試環(huán)境時(shí)候業(yè)務(wù)系統(tǒng)一開始寫的SQL沒有考慮太多的優(yōu)化可能會(huì)出現(xiàn)比較多的慢SQL，這些慢SQL我們都會(huì)統(tǒng)一采集在JMonitor系統(tǒng)上進(jìn)行分析處理，幫助業(yè)務(wù)方快速迭代調(diào)整SQL語句。

圖11 監(jiān)控體系

業(yè)務(wù)在使用這套系統(tǒng)的時(shí)候 要盡量出現(xiàn)避免跨庫的SQL，有一個(gè)很重要的原因是當(dāng)出現(xiàn)跨庫SQL的時(shí)候會(huì)耗費(fèi)MySQL較多的連接如圖12所示，一條不帶拆分字段的SQL將會(huì)發(fā)送到所有的分片上，如果在一個(gè)MySQL實(shí)例上有64個(gè)分片，那一條這樣的SQL就會(huì)耗費(fèi)這個(gè)MySQL實(shí)例上的64個(gè)連接，這個(gè)資源消耗是非常可觀的，如果可以控制SQL落在單個(gè)分片上可以大大降低MySQL實(shí)例上的連接壓力。

圖12 連接數(shù)

跨庫的分布式事務(wù)要要盡量避免，一個(gè)是基于MySQL的分布式數(shù)據(jù)庫中間件的方案無法保證嚴(yán)格的分布式事務(wù)語義，另一個(gè)即使可以做到嚴(yán)格的分布式事務(wù)語義支持依然是要盡量避免垮庫事務(wù)的，多個(gè)跨庫的分布式事務(wù)在某個(gè)分片上發(fā)生死鎖將會(huì)造成其他分片上的事務(wù)也無法繼續(xù)導(dǎo)致直接引起大面積的死鎖，即使是單節(jié)點(diǎn)上的事務(wù)也要盡量控制事務(wù)小一點(diǎn)，降低死鎖發(fā)生的概率。

具體的路由策略不同的業(yè)務(wù)可以特殊對待，以京東分揀中心為例，各個(gè)分揀中心的大小差異很大，北京上海等大城市的分揀中心數(shù)據(jù)量很大其他城市的分揀中心相對會(huì)小一點(diǎn)， 針對這種特點(diǎn)我們會(huì)給其定制路由策略，做到將大的分揀中心的數(shù)據(jù)落在特定的性能較好的MySQL實(shí)例上，其他小的分揀中心的數(shù)據(jù)可以按照普通的拆分方式處理。

在JProxy系統(tǒng)層面我們可以支持多租戶模式，但考慮到去Oracle/SqlServer的業(yè)務(wù)往往都是非常重要且數(shù)據(jù)量巨大的業(yè)務(wù)，所以我們的系統(tǒng)都是不同的業(yè)務(wù)獨(dú)立部署一套，在部署層面避免各個(gè)業(yè)務(wù)之間的互相影響。考慮到獨(dú)立部署會(huì)造成一些資源浪費(fèi)，我們引入了容器系統(tǒng)，將操作系統(tǒng)資源通過容器的方式進(jìn)行隔離，從而保證系統(tǒng)資源的充分利用。很多問題沒必要一定要在代碼層面解決，代碼層面解決起來比較麻煩或者不能做到百分之百把控的事情可以通過架構(gòu)層面來解決，架構(gòu)層面不好解決的事情可以通過部署的層面來解決，部署層面不好解決的事情可以通過產(chǎn)品層面來解決，解決問題的方式各式各樣，需要從整個(gè)系統(tǒng)全局角度來綜合考量，引用鄧公的一句話“不管黑貓白貓，能抓老鼠的就是好貓”，同樣的道理能支撐住業(yè)務(wù)發(fā)展的系統(tǒng)就是好的系統(tǒng)。

另外再簡單討論一下為什么基于MySQL的分布式數(shù)據(jù)庫中間件系統(tǒng)無法保證嚴(yán)格的分布式事務(wù)語義支持。所謂分布式事務(wù)語義本質(zhì)上就是事務(wù)的語義，包含了ACID屬性，分別是原子性、一致性、持久性、隔離性。

原子性是指一個(gè)事務(wù)要么成功要么失敗，不能存在中間狀態(tài)。持久性是指一個(gè)事務(wù)一旦提交成功那么要做到系統(tǒng)崩潰以后再恢復(fù)依然是成功的。隔離性是指各個(gè)并發(fā)事務(wù)之間是隔離的，不可見的，在數(shù)據(jù)庫具體實(shí)現(xiàn)上可能會(huì)分很多個(gè)隔離級別。事務(wù)的一致性是指要保證系統(tǒng)要處于一個(gè)一致的狀態(tài)，比如從A賬戶轉(zhuǎn)了500元到B賬戶，那么從整體系統(tǒng)來看系統(tǒng)的總金額是沒有發(fā)生變化的，不能出現(xiàn)A的賬戶已經(jīng)減去500元但是B賬戶卻沒有增加500元的情況。

圖13 可串行化調(diào)度

事務(wù)在數(shù)據(jù)庫系統(tǒng)中執(zhí)行的時(shí)候有一個(gè)可串行化調(diào)度的問題，假設(shè)有T1、T2、T3三個(gè)事務(wù)，那么這三個(gè)事務(wù)的執(zhí)行的效果應(yīng)該和三個(gè)事務(wù)串行執(zhí)行效果一樣，也就是最終效果效果應(yīng)該是{T1/T2/T3, T1/T3/T2, T2/T1/T3, T2/T3/T1, T3/T1/T2, T3/T2/T1}集合中的一個(gè)，當(dāng)涉及到分布式事務(wù)時(shí)，每個(gè)子事務(wù)之間的調(diào)度要和全局的分布式事務(wù)的調(diào)度順序一致才能滿足可串行化調(diào)度的要求，如圖13所示，T1/T2/T3的三個(gè)分布式事務(wù)，在一個(gè)庫中的調(diào)度順序是T1/T2/T3和全局的調(diào)度順序一致，在另一個(gè)庫中的調(diào)度順序變成了T3/T2/T1，此時(shí)站在全局的角度來看就打破了可串行化調(diào)度，可串行化調(diào)度保證了隔離性的實(shí)現(xiàn)，當(dāng)可串行化調(diào)度被打破時(shí)自然隔離性也就隨之打破，在基于MySQL的分布式中間件方案實(shí)現(xiàn)上，因?yàn)橥粋€(gè)分布式事務(wù)的各個(gè)子事務(wù)的事務(wù)ID是在各個(gè)MySQL上生成的，并沒有提供全局的事務(wù)ID來保證各個(gè)子事務(wù)的調(diào)度順序和全局的分布式事務(wù)一致，導(dǎo)致隔離性是無法保證的，所以說當(dāng)前基于MySQL的分布式事務(wù)是無法保證嚴(yán)格的分布式事務(wù)語義支持的。當(dāng)然隨著MySQL引入GR可以做到CAP理論中的強(qiáng)一致，再加強(qiáng)中間件的相關(guān)功能及定制MySQL相關(guān)功能也是有可能做到支持嚴(yán)格的分布式事務(wù)的。

文章轉(zhuǎn)自（）

最流行的開源關(guān)系型數(shù)據(jù)庫管理系統(tǒng)MySQL點(diǎn)擊下載>>>