什么是New SQL?分析NewSQL是如何融合NoSQL和RDBMS兩者的優(yōu)勢

NewSQL是對一類現(xiàn)代關(guān)系型數(shù)據(jù)庫的統(tǒng)稱，這類數(shù)據(jù)庫對于一般的OLTP讀寫請求提供可橫向擴(kuò)展的性能，同時(shí)支持事務(wù)的ACID保證。這些系統(tǒng)既擁有NoSQL數(shù)據(jù)庫的擴(kuò)展性，又保持傳統(tǒng)數(shù)據(jù)庫的事務(wù)特性。NewSQL重新將“應(yīng)用程序邏輯與數(shù)據(jù)操作邏輯應(yīng)該分離”的理念帶回到現(xiàn)代數(shù)據(jù)庫的世界，這也驗(yàn)證了歷史的發(fā)展總是呈現(xiàn)出螺旋上升的形式。

公司主營業(yè)務(wù)：成都做網(wǎng)站、成都網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出肇州免費(fèi)做網(wǎng)站回饋大家。

在21世紀(jì)00年代中，出現(xiàn)了許多數(shù)據(jù)倉庫系統(tǒng) (如 Vertica，Greeplum 和AsterData)，這些以處理OLAP 請求為設(shè)計(jì)目標(biāo)的系統(tǒng)并不在本文定義的NewSQL范圍內(nèi)。OLAP 數(shù)據(jù)庫更關(guān)注針對海量數(shù)據(jù)的大型、復(fù)雜、只讀的查詢，查詢時(shí)間可能持續(xù)秒級、分鐘級甚至更長。

NoSQL的擁躉普遍認(rèn)為阻礙傳統(tǒng)數(shù)據(jù)庫橫向擴(kuò)容、提高可用性的原因在于ACID保證和關(guān)系模型，因此NoSQL運(yùn)動(dòng)的核心就是放棄事務(wù)強(qiáng)一致性以及關(guān)系模型，擁抱最終一致性和其它數(shù)據(jù)模型?(如 key/value，graphs 和Documents)。

兩個(gè)最著名的NoSQL數(shù)據(jù)庫就是Google的BigTable和Amazon的Dynamo，由于二者都未開源，其它組織就開始推出類似的開源替代項(xiàng)目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創(chuàng)業(yè)公司也加入到這場NoSQL運(yùn)動(dòng)中，它們不一定是受BigTable和Dynamo的啟發(fā)，但都響應(yīng)了NoSQL的哲學(xué)，其中最出名的就是MongoDB。

在21世紀(jì)00年代末，市面上已經(jīng)有許多供用戶選擇的分布式數(shù)據(jù)庫產(chǎn)品。使用NoSQL的優(yōu)勢在于應(yīng)用開發(fā)者可以更關(guān)注應(yīng)用邏輯本身，而非數(shù)據(jù)庫的擴(kuò)展性問題；但與此同時(shí)許多應(yīng)用，如金融系統(tǒng)、訂單處理系統(tǒng)，由于無法放棄事務(wù)的一致性要求被拒之門外。

一些組織，如Google，已經(jīng)發(fā)現(xiàn)他們的許多工程師將過多的精力放在處理數(shù)據(jù)一致性上，這既暴露了數(shù)據(jù)庫的抽象、又提高了代碼的復(fù)雜度，這時(shí)候要么選擇回到傳統(tǒng)DBMS時(shí)代，用更高的機(jī)器配置縱向擴(kuò)容，要么選擇回到中間件時(shí)代，開發(fā)支持分布式事務(wù)的中間件。這兩種方案成本都很高，于是NewSQL運(yùn)動(dòng)開始醞釀。

NewSQL數(shù)據(jù)庫設(shè)計(jì)針對的讀寫事務(wù)有以下特點(diǎn)：

1、耗時(shí)短。

2、使用索引查詢，涉及少量數(shù)據(jù)。

3、重復(fù)度高，通常使用相同的查詢語句和不同的查詢參考。

也有一些學(xué)者認(rèn)為NewSQL系統(tǒng)是特指實(shí)現(xiàn)上使用Lock-free并發(fā)控制技術(shù)和share-nothing架構(gòu)的數(shù)據(jù)庫。所有我們認(rèn)為是NewSQL的數(shù)據(jù)庫系統(tǒng)確實(shí)都有這樣的特點(diǎn)。

為什么說分布式事務(wù)不再適用于微服務(wù)架構(gòu)

樓主這個(gè)說法很標(biāo)準(zhǔn)，不是不可用，只是不適用。我們看下為什么分布式事務(wù)不再適用于微服務(wù)架構(gòu)。

多個(gè)微服務(wù)應(yīng)用就構(gòu)成了分布式系統(tǒng)，由此會(huì)帶來固有的復(fù)雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當(dāng)然這并不是什么難事，但相對于單體式應(yīng)用中通過語言層級的方法或者進(jìn)程調(diào)用，微服務(wù)下這種技術(shù)顯得更復(fù)雜一些。

另外一個(gè)關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時(shí)給多個(gè)業(yè)務(wù)分主體更新消息很普遍。這種交易對于單體式應(yīng)用來說很容易，因?yàn)橹挥幸粋€(gè)數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因?yàn)镃AP理論，還因?yàn)榻裉旄邤U(kuò)展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個(gè)最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

部署一個(gè)微服務(wù)應(yīng)用也很復(fù)雜，一個(gè)分布式應(yīng)用只需要簡單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了。每個(gè)應(yīng)用實(shí)例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)。相對比，一個(gè)微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成。例如，根據(jù)Adrian Cockcroft，Hailo有160個(gè)不同服務(wù)構(gòu)成，NetFlix有大約600個(gè)服務(wù)。每個(gè)服務(wù)都有多個(gè)實(shí)例。這就造成許多需要配置、部署、擴(kuò)展和監(jiān)控的部分，除此之外，你還需要完成一個(gè)服務(wù)發(fā)現(xiàn)機(jī)制，以用來發(fā)現(xiàn)與它通訊服務(wù)的地址（包括服務(wù)器地址和端口）。傳統(tǒng)的解決問題辦法不能用于解決這么復(fù)雜的問題。接續(xù)而來，成功部署一個(gè)微服務(wù)應(yīng)用需要開發(fā)者有足夠的控制部署方法，并高度自動(dòng)化。

總而言之，一句話概括，由于每個(gè)微服務(wù)實(shí)現(xiàn)方式五花八門，當(dāng)微服務(wù)多了情況下，一個(gè)服務(wù)流程可能會(huì)涉及多個(gè)服務(wù)，如果這些微服務(wù)耦合過于強(qiáng)，那必然要確保其事務(wù)的一致性，但是這是個(gè)及其困難的事情。

newsql和nosql的區(qū)別和聯(lián)系

在大數(shù)據(jù)時(shí)代，“多種架構(gòu)支持多類應(yīng)用”成為數(shù)據(jù)庫行業(yè)應(yīng)對大數(shù)據(jù)的基本思路，數(shù)據(jù)庫行業(yè)出現(xiàn)互為補(bǔ)充的三大陣營，適用于事務(wù)處理應(yīng)用的OldSQL、適用于數(shù)據(jù)分析應(yīng)用的NewSQL和適用于互聯(lián)網(wǎng)應(yīng)用的NoSQL。但在一些復(fù)雜的應(yīng)用場景中，單一數(shù)據(jù)庫架構(gòu)都不能完全滿足應(yīng)用場景對海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)管理、復(fù)雜分析、關(guān)聯(lián)查詢、實(shí)時(shí)性處理和控制建設(shè)成本等多方面的需要，因此不同架構(gòu)數(shù)據(jù)庫混合部署應(yīng)用成為滿足復(fù)雜應(yīng)用的必然選擇。不同架構(gòu)數(shù)據(jù)庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個(gè)案例對不同架構(gòu)數(shù)據(jù)庫的混合應(yīng)用部署進(jìn)行介紹。

OldSQL+NewSQL 在數(shù)據(jù)中心類應(yīng)用中混合部署

采用OldSQL+NewSQL模式構(gòu)建數(shù)據(jù)中心，在充分發(fā)揮OldSQL數(shù)據(jù)庫的事務(wù)處理能力的同時(shí)，借助NewSQL在實(shí)時(shí)性、復(fù)雜分析、即席查詢等方面的獨(dú)特優(yōu)勢，以及面對海量數(shù)據(jù)時(shí)較強(qiáng)的擴(kuò)展能力，滿足數(shù)據(jù)中心對當(dāng)前“熱”數(shù)據(jù)事務(wù)型處理和海量歷史“冷”數(shù)據(jù)分析兩方面的需求。OldSQL+NewSQL模式在數(shù)據(jù)中心類應(yīng)用中的互補(bǔ)作用體現(xiàn)在，OldSQL彌補(bǔ)了NewSQL不適合事務(wù)處理的不足，NewSQL彌補(bǔ)了OldSQL在海量數(shù)據(jù)存儲(chǔ)能力和處理性能方面的缺陷。

商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數(shù)據(jù)庫滿足各業(yè)務(wù)系統(tǒng)數(shù)據(jù)的歸檔備份和事務(wù)型應(yīng)用，NewSQL MPP數(shù)據(jù)庫集群對即席查詢、多維分析等應(yīng)用提供高性能支持，并且通過MPP集群架構(gòu)實(shí)現(xiàn)應(yīng)對海量數(shù)據(jù)存儲(chǔ)的擴(kuò)展能力。

商業(yè)銀行數(shù)據(jù)中心存儲(chǔ)架構(gòu)

與傳統(tǒng)的OldSQL模式相比，商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合搭建模式，數(shù)據(jù)加載性能提升3倍以上，即席查詢和統(tǒng)計(jì)分析性能提升6倍以上。NewSQL MPP的高可擴(kuò)展性能夠應(yīng)對新的業(yè)務(wù)需求，可隨著數(shù)據(jù)量的增長采用集群方式構(gòu)建存儲(chǔ)容量更大的數(shù)據(jù)中心。

OldSQL+NoSQL 在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中混合部署

在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中采用OldSQL+NoSQL混合模式，能夠很好的解決互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用對海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行存儲(chǔ)和快速處理的需求。在諸如大型電子商務(wù)平臺(tái)、大型SNS平臺(tái)等互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用場景中，OldSQL在應(yīng)用中負(fù)責(zé)高價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和事務(wù)型處理，NoSQL在應(yīng)用中負(fù)責(zé)存儲(chǔ)和處理海量非結(jié)構(gòu)化的數(shù)據(jù)和低價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)。OldSQL+NoSQL模式在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中的互補(bǔ)作用體現(xiàn)在，OldSQL彌補(bǔ)了NoSQL在ACID特性和復(fù)雜關(guān)聯(lián)運(yùn)算方面的不足，NoSQL彌補(bǔ)了OldSQL在海量數(shù)據(jù)存儲(chǔ)和非結(jié)構(gòu)化數(shù)據(jù)處理方面的缺陷。

數(shù)據(jù)魔方是淘寶網(wǎng)的一款數(shù)據(jù)產(chǎn)品，主要提供行業(yè)數(shù)據(jù)分析、店鋪數(shù)據(jù)分析。淘寶數(shù)據(jù)產(chǎn)品在存儲(chǔ)層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關(guān)系型數(shù)據(jù)庫集群MyFOX和基于HBase的NoSQL存儲(chǔ)集群Prom組成。由于OldSQL強(qiáng)大的語義和關(guān)系表達(dá)能力，在應(yīng)用中仍然占據(jù)著重要地位，目前存儲(chǔ)在MyFOX中的統(tǒng)計(jì)結(jié)果數(shù)據(jù)已經(jīng)達(dá)到10TB，占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù)量的95%以上。另一方面，NoSQL作為SQL的有益補(bǔ)充，解決了OldSQL數(shù)據(jù)庫無法解決的全屬性選擇器等問題。

淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)

基于OldSQL+NoSQL混合架構(gòu)的特點(diǎn)，數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲(chǔ)空間，支持每天4000萬的查詢請求，平均響應(yīng)時(shí)間在28毫秒，足以滿足未來一段時(shí)間內(nèi)的業(yè)務(wù)增長需求。

NewSQL+NoSQL 在行業(yè)大數(shù)據(jù)應(yīng)用中混合部署

行業(yè)大數(shù)據(jù)與互聯(lián)網(wǎng)大數(shù)據(jù)的區(qū)別在于行業(yè)大數(shù)據(jù)的價(jià)值密度更高，并且對結(jié)構(gòu)化數(shù)據(jù)的實(shí)時(shí)處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強(qiáng)一致性等都比互聯(lián)網(wǎng)大數(shù)據(jù)有更高的要求。行業(yè)大數(shù)據(jù)應(yīng)用場景主要是分析類應(yīng)用，如：電信、金融、政務(wù)、能源等行業(yè)的決策輔助、預(yù)測預(yù)警、統(tǒng)計(jì)分析、經(jīng)營分析等。

在行業(yè)大數(shù)據(jù)應(yīng)用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結(jié)構(gòu)化數(shù)據(jù)分析處理方面的優(yōu)勢，以及NoSQL在非結(jié)構(gòu)數(shù)據(jù)處理方面的優(yōu)勢，實(shí)現(xiàn)NewSQL與NoSQL的功能互補(bǔ)，解決行業(yè)大數(shù)據(jù)應(yīng)用對高價(jià)值結(jié)構(gòu)化數(shù)據(jù)的實(shí)時(shí)處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強(qiáng)一致性等要求，以及對海量非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)和精確查詢的要求。在應(yīng)用中，NewSQL承擔(dān)高價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和分析處理工作，NoSQL承擔(dān)存儲(chǔ)和處理海量非結(jié)構(gòu)化數(shù)據(jù)和不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的低價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的工作。

當(dāng)前電信運(yùn)營商在集中化BI系統(tǒng)建設(shè)過程中面臨著數(shù)據(jù)規(guī)模大、數(shù)據(jù)處理類型多等問題，并且需要應(yīng)對大量的固定應(yīng)用，以及占統(tǒng)計(jì)總數(shù)80%以上的突發(fā)性臨時(shí)統(tǒng)計(jì)(ad-hoc)需求。在集中化BI系統(tǒng)的建設(shè)中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復(fù)雜分析、即席查詢等方面處理性能的優(yōu)勢，及NoSQL在非結(jié)構(gòu)化數(shù)據(jù)處理和海量數(shù)據(jù)存儲(chǔ)方面的優(yōu)勢，實(shí)現(xiàn)高效低成本。

集中化BI系統(tǒng)數(shù)據(jù)存儲(chǔ)架構(gòu)

集中化BI系統(tǒng)按照數(shù)據(jù)類型和處理方式的不同，將結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)分別存儲(chǔ)在不同的系統(tǒng)中：非結(jié)構(gòu)化數(shù)據(jù)在Hadoop平臺(tái)上存儲(chǔ)與處理;結(jié)構(gòu)化、不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的數(shù)據(jù)保存在NoSQL數(shù)據(jù)庫或Hadoop平臺(tái);結(jié)構(gòu)化、需要關(guān)聯(lián)分析或經(jīng)常ad-hoc查詢的數(shù)據(jù)，保存在NewSQL MPP數(shù)據(jù)庫中，短期高價(jià)值數(shù)據(jù)放在高性能平臺(tái)，中長期放在低成本產(chǎn)品中。

結(jié)語

當(dāng)前信息化應(yīng)用的多樣性、復(fù)雜性，以及三種數(shù)據(jù)庫架構(gòu)各自所具有的優(yōu)勢和局限性，造成任何一種架構(gòu)的數(shù)據(jù)庫都不能完全滿足應(yīng)用需求，因此不同架構(gòu)數(shù)據(jù)庫混合使用，從而彌補(bǔ)其他架構(gòu)的不足成為必然選擇。根據(jù)應(yīng)用場景采用不同架構(gòu)數(shù)據(jù)庫進(jìn)行組合搭配，充分發(fā)揮每種架構(gòu)數(shù)據(jù)庫的特點(diǎn)和優(yōu)勢，并且與其他架構(gòu)數(shù)據(jù)庫形成互補(bǔ)，完全涵蓋應(yīng)用需求，保證數(shù)據(jù)資源的最優(yōu)化利用，將成為未來一段時(shí)期內(nèi)信息化應(yīng)用主要采用的解決方式。

目前在國內(nèi)市場上，OldSQL主要為Oracle、IBM等國外數(shù)據(jù)庫廠商所壟斷，達(dá)夢、金倉等國產(chǎn)廠商仍處于追趕狀態(tài);南大通用憑借國產(chǎn)新型數(shù)據(jù)庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強(qiáng);NoSQL方面用戶則大多采用Hadoop開源方案。

為什么大部分NoSQL不提供分布式事務(wù)

像MongoDB, Cassandra, HBase, DynamoDB, 和

Riak這些NoSQL缺乏傳統(tǒng)的原子事務(wù)機(jī)制，所謂原子事務(wù)機(jī)制是可以保證一系列寫操作要么全部完成，要么全部不會(huì)完成，不會(huì)發(fā)生只完成一系列中一兩個(gè)

寫操作;因?yàn)閿?shù)據(jù)庫不提供這種事務(wù)機(jī)制支持，開發(fā)者需要自己編寫代碼來確保一系列寫操作的事務(wù)機(jī)制，比較復(fù)雜和測試。

這些NoSQL數(shù)據(jù)庫不提供事務(wù)機(jī)制原因在于其分布式特點(diǎn)，一系列寫操作中訪問的數(shù)據(jù)可能位于不同的分區(qū)服務(wù)器，這樣的事務(wù)就變成分布式事務(wù)，在分

布式事務(wù)中實(shí)現(xiàn)原子性需要彼此協(xié)調(diào)，而協(xié)調(diào)是耗費(fèi)時(shí)間的，每臺(tái)機(jī)器在一個(gè)大事務(wù)過程中必須依次確認(rèn)，這就需要一種協(xié)議確保一個(gè)事務(wù)中沒有任何一臺(tái)機(jī)器寫操

作失敗。

這種協(xié)調(diào)是昂貴的，會(huì)增加延遲時(shí)間，關(guān)鍵問題是，當(dāng)協(xié)調(diào)沒有完成時(shí)，其他操作是不能讀取事務(wù)中寫操作結(jié)果的，這是因?yàn)槭聞?wù)的all-or-

nothing原理導(dǎo)致，萬一協(xié)調(diào)過程發(fā)現(xiàn)某個(gè)寫操作不能完成，那么需要將其他寫操作成功的進(jìn)行回滾。針對分布式事務(wù)的分布式協(xié)調(diào)對整體數(shù)據(jù)庫性能有嚴(yán)重

影響，不只是吞吐量還包括延遲時(shí)間，這樣大部分NoSQL數(shù)據(jù)庫因?yàn)樾阅軉栴}就選擇不提供分布式事務(wù)。

MongoDB, Riak, HBase, 和 Cassandra提供基于單一鍵的事務(wù)，這是因?yàn)樗行畔⒍己鸵粋€(gè)鍵key有關(guān)，這個(gè)鍵是存儲(chǔ)在單個(gè)服務(wù)器上，這樣基于單鍵的事務(wù)不會(huì)帶來復(fù)雜的分布式協(xié)調(diào)。

那么看來擴(kuò)展性性能和分布式事務(wù)是一對矛盾，總要有取舍?實(shí)際上是不完全是，現(xiàn)在完全有可能提供高擴(kuò)展的性能同時(shí)提供分布式原子事務(wù)。

FIT是這樣一個(gè)在分布式系統(tǒng)提供原子事務(wù)的策略，在fairness公平性, isolation隔離性, 和throughput吞吐量(簡稱FIT)可以權(quán)衡。

一個(gè)支持分布式事務(wù)的可伸縮分布式系統(tǒng)能夠完成這三個(gè)屬性中兩個(gè)，公平是事務(wù)之間不會(huì)相互影響造成延遲;隔離性提供一種幻覺好像整個(gè)數(shù)據(jù)庫只有它自

己一個(gè)事務(wù)，隔離性保證當(dāng)任何同時(shí)發(fā)生的事務(wù)發(fā)生沖突時(shí)，能夠保證彼此能看到彼此的寫操作結(jié)果，因此減輕了程序員為避免事務(wù)讀寫沖突的強(qiáng)邏輯推理要求;吞

吐量是指每單元時(shí)間數(shù)據(jù)庫能夠并發(fā)處理多少事務(wù)。

FIT是如下進(jìn)行權(quán)衡：

保證公平性fairness 和隔離性isolation, 但是犧牲吞吐量

保證公平性fairness和吞吐量, 犧牲隔離性isolation

保證隔離性isolation和吞吐量throughput, 但是犧牲公平性fairness.

犧牲公平性：放棄公平性，數(shù)據(jù)庫能有更多機(jī)會(huì)降低分布式事務(wù)的成本，主要成本是分布式協(xié)調(diào)帶來的，也就是說，不需要在每個(gè)事務(wù)過程內(nèi)對每個(gè)機(jī)器都依

次確認(rèn)事務(wù)完成，這樣排隊(duì)式的確認(rèn)commit事務(wù)是很浪費(fèi)時(shí)間的，放棄公平性，意味著可以在事務(wù)外面進(jìn)行協(xié)調(diào)，這樣就只是增加了協(xié)調(diào)時(shí)間，不會(huì)增加互相

沖突事務(wù)因?yàn)楸舜藳_突而不能運(yùn)行所耽擱的時(shí)間，當(dāng)系統(tǒng)不需要公平性時(shí)，需要根據(jù)事務(wù)的優(yōu)先級或延遲等標(biāo)準(zhǔn)進(jìn)行指定先后執(zhí)行順序，這樣就能夠獲得很好的吞吐

量。

G-Store是一種放棄公平性的 Isolation-Throughput

的分布式key-value存儲(chǔ)，支持多鍵事務(wù)(multi-key transactions)，MongoDB 和

HBase在鍵key在同樣分區(qū)上也支持多鍵事務(wù)，但是不支持跨分區(qū)的事務(wù)。

總之：傳統(tǒng)分布式事務(wù)性能不佳的原因是確保原子性(分布式協(xié)調(diào))和隔離性同時(shí)重疊，創(chuàng)建一個(gè)高吞吐量分布式事務(wù)的關(guān)鍵是分離這兩種關(guān)注，這種分離原

子性和隔離性的視角將導(dǎo)致兩種類型的系統(tǒng)，第一種選擇是弱隔離性能讓沖突事務(wù)并行執(zhí)行和確認(rèn)提交;第二個(gè)選擇重新排序原子性和隔離性機(jī)制保證它們不會(huì)某個(gè)

時(shí)間重疊，這是一種放棄公平的事務(wù)執(zhí)行，所謂放棄公平就是不再同時(shí)照顧原子性和隔離性了，有所傾斜，放棄高標(biāo)準(zhǔn)道德要求就會(huì)帶來高自由高效率。

深入理解分布式事務(wù)，高并發(fā)下分布式事務(wù)的解決方案

1、什么是分布式事務(wù)

分布式事務(wù)就是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上。以上是百度百科的解釋，簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務(wù)器上，且屬于不同的應(yīng)用，分布式事務(wù)需要保證這些小操作要么全部成功，要么全部失敗。本質(zhì)上來說，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

2、分布式事務(wù)的產(chǎn)生的原因

2.1、數(shù)據(jù)庫分庫分表

當(dāng)數(shù)據(jù)庫單表一年產(chǎn)生的數(shù)據(jù)超過1000W，那么就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以后有空詳細(xì)說，簡單的說就是原來的一個(gè)數(shù)據(jù)庫變成了多個(gè)數(shù)據(jù)庫。這時(shí)候，如果一個(gè)操作既訪問01庫，又訪問02庫，而且要保證數(shù)據(jù)的一致性，那么就要用到分布式事務(wù)。

2.2、應(yīng)用SOA化

所謂的SOA化，就是業(yè)務(wù)的服務(wù)化。比如原來單機(jī)支撐了整個(gè)電商網(wǎng)站，現(xiàn)在對整個(gè)網(wǎng)站進(jìn)行拆解，分離出了訂單中心、用戶中心、庫存中心。對于訂單中心，有專門的數(shù)據(jù)庫存儲(chǔ)訂單信息，用戶中心也有專門的數(shù)據(jù)庫存儲(chǔ)用戶信息，庫存中心也會(huì)有專門的數(shù)據(jù)庫存儲(chǔ)庫存信息。這時(shí)候如果要同時(shí)對訂單和庫存進(jìn)行操作，那么就會(huì)涉及到訂單數(shù)據(jù)庫和庫存數(shù)據(jù)庫，為了保證數(shù)據(jù)一致性，就需要用到分布式事務(wù)。

以上兩種情況表象不同，但是本質(zhì)相同，都是因?yàn)橐僮鞯臄?shù)據(jù)庫變多了！

3、事務(wù)的ACID特性

3.1、原子性（A）

所謂的原子性就是說，在整個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不做，沒有中間狀態(tài)。對于事務(wù)在執(zhí)行中發(fā)生錯(cuò)誤，所有的操作都會(huì)被回滾，整個(gè)事務(wù)就像從沒被執(zhí)行過一樣。

3.2、一致性（C）

事務(wù)的執(zhí)行必須保證系統(tǒng)的一致性，就拿轉(zhuǎn)賬為例，A有500元，B有300元，如果在一個(gè)事務(wù)里A成功轉(zhuǎn)給B50元，那么不管并發(fā)多少，不管發(fā)生什么，只要事務(wù)執(zhí)行成功了，那么最后A賬戶一定是450元，B賬戶一定是350元。

3.3、隔離性（I）

所謂的隔離性就是說，事務(wù)與事務(wù)之間不會(huì)互相影響，一個(gè)事務(wù)的中間狀態(tài)不會(huì)被其他事務(wù)感知。

3.4、持久性（D）

所謂的持久性，就是說一單事務(wù)完成了，那么事務(wù)對數(shù)據(jù)所做的變更就完全保存在了數(shù)據(jù)庫中，即使發(fā)生停電，系統(tǒng)宕機(jī)也是如此。

4、分布式事務(wù)的應(yīng)用場景

4.1、支付

最經(jīng)典的場景就是支付了，一筆支付，是對買家賬戶進(jìn)行扣款，同時(shí)對賣家賬戶進(jìn)行加錢，這些操作必須在一個(gè)事務(wù)里執(zhí)行，要么全部成功，要么全部失敗。而對于買家賬戶屬于買家中心，對應(yīng)的是買家數(shù)據(jù)庫，而賣家賬戶屬于賣家中心，對應(yīng)的是賣家數(shù)據(jù)庫，對不同數(shù)據(jù)庫的操作必然需要引入分布式事務(wù)。

4.2、在線下單

買家在電商平臺(tái)下單，往往會(huì)涉及到兩個(gè)動(dòng)作，一個(gè)是扣庫存，第二個(gè)是更新訂單狀態(tài)，庫存和訂單一般屬于不同的數(shù)據(jù)庫，需要使用分布式事務(wù)保證數(shù)據(jù)一致性。

5、常見的分布式事務(wù)解決方案

5.1、基于XA協(xié)議的兩階段提交

XA是一個(gè)分布式事務(wù)協(xié)議，由Tuxedo提出。XA中大致分為兩部分：事務(wù)管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫實(shí)現(xiàn)，比如Oracle、DB2這些商業(yè)數(shù)據(jù)庫都實(shí)現(xiàn)了XA接口，而事務(wù)管理器作為全局的調(diào)度者，負(fù)責(zé)各個(gè)本地資源的提交和回滾。XA實(shí)現(xiàn)分布式事務(wù)的原理如下：

總的來說，XA協(xié)議比較簡單，而且一旦商業(yè)數(shù)據(jù)庫實(shí)現(xiàn)了XA協(xié)議，使用分布式事務(wù)的成本也比較低。但是，XA也有致命的缺點(diǎn)，那就是性能不理想，特別是在交易下單鏈路，往往并發(fā)量很高，XA無法滿足高并發(fā)場景。XA目前在商業(yè)數(shù)據(jù)庫支持的比較理想，在mysql數(shù)據(jù)庫中支持的不太理想，mysql的XA實(shí)現(xiàn)，沒有記錄prepare階段日志，主備切換回導(dǎo)致主庫與備庫數(shù)據(jù)不一致。許多nosql也沒有支持XA，這讓XA的應(yīng)用場景變得非常狹隘。

5.2、消息事務(wù)+最終一致性

所謂的消息事務(wù)就是基于消息中間件的兩階段提交，本質(zhì)上是對消息中間件的一種特殊利用，它是將本地事務(wù)和發(fā)消息放在了一個(gè)分布式事務(wù)里，保證要么本地操作成功成功并且對外發(fā)消息成功，要么兩者都失敗，開源的RocketMQ就支持這一特性，具體原理如下：

1、A系統(tǒng)向消息中間件發(fā)送一條預(yù)備消息

2、消息中間件保存預(yù)備消息并返回成功

3、A執(zhí)行本地事務(wù)

4、A發(fā)送提交消息給消息中間件

通過以上4步完成了一個(gè)消息事務(wù)。對于以上的4個(gè)步驟，每個(gè)步驟都可能產(chǎn)生錯(cuò)誤，下面一一分析：

步驟一出錯(cuò)，則整個(gè)事務(wù)失敗，不會(huì)執(zhí)行A的本地操作步驟二出錯(cuò)，則整個(gè)事務(wù)失敗，不會(huì)執(zhí)行A的本地操作步驟三出錯(cuò)，這時(shí)候需要回滾預(yù)備消息，怎么回滾？答案是A系統(tǒng)實(shí)現(xiàn)一個(gè)消息中間件的回調(diào)接口，消息中間件會(huì)去不斷執(zhí)行回調(diào)接口，檢查A事務(wù)執(zhí)行是否執(zhí)行成功，如果失敗則回滾預(yù)備消息步驟四出錯(cuò)，這時(shí)候A的本地事務(wù)是成功的，那么消息中間件要回滾A嗎？答案是不需要，其實(shí)通過回調(diào)接口，消息中間件能夠檢查到A執(zhí)行成功了，這時(shí)候其實(shí)不需要A發(fā)提交消息了，消息中間件可以自己對消息進(jìn)行提交，從而完成整個(gè)消息事務(wù)基于消息中間件的兩階段提交往往用在高并發(fā)場景下，將一個(gè)分布式事務(wù)拆成一個(gè)消息事務(wù)（A系統(tǒng)的本地操作+發(fā)消息）+B系統(tǒng)的本地操作，其中B系統(tǒng)的操作由消息驅(qū)動(dòng)，只要消息事務(wù)成功，那么A操作一定成功，消息也一定發(fā)出來了，這時(shí)候B會(huì)收到消息去執(zhí)行本地操作，如果本地操作失敗，消息會(huì)重投，直到B操作成功，這樣就變相地實(shí)現(xiàn)了A與B的分布式事務(wù)。原理如下：

雖然上面的方案能夠完成A和B的操作，但是A和B并不是嚴(yán)格一致的，而是最終一致的，我們在這里犧牲了一致性，換來了性能的大幅度提升。當(dāng)然，這種玩法也是有風(fēng)險(xiǎn)的，如果B一直執(zhí)行不成功，那么一致性會(huì)被破壞，具體要不要玩，還是得看業(yè)務(wù)能夠承擔(dān)多少風(fēng)險(xiǎn)。

5.3、TCC編程模式

所謂的TCC編程模式，也是兩階段提交的一個(gè)變種。TCC提供了一個(gè)編程框架，將整個(gè)業(yè)務(wù)邏輯分為三塊：Try、Confirm和Cancel三個(gè)操作。以在線下單為例，Try階段會(huì)去扣庫存，Confirm階段則是去更新訂單狀態(tài)，如果更新訂單失敗，則進(jìn)入Cancel階段，會(huì)去恢復(fù)庫存?？傊琓CC就是通過代碼人為實(shí)現(xiàn)了兩階段提交，不同的業(yè)務(wù)場景所寫的代碼都不一樣，復(fù)雜度也不一樣，因此，這種模式并不能很好地被復(fù)用。

6、總結(jié)

分布式事務(wù)，本質(zhì)上是對多個(gè)數(shù)據(jù)庫的事務(wù)進(jìn)行統(tǒng)一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務(wù)，部分控制就是各種變種的兩階段提交，包括上面提到的消息事務(wù)+最終一致性、TCC模式，而完全控制就是完全實(shí)現(xiàn)兩階段提交。部分控制的好處是并發(fā)量和性能很好，缺點(diǎn)是數(shù)據(jù)一致性減弱了，完全控制則是犧牲了性能，保障了一致性，具體用哪種方式，最終還是取決于業(yè)務(wù)場景。作為技術(shù)人員，一定不能忘了技術(shù)是為業(yè)務(wù)服務(wù)的，不要為了技術(shù)而技術(shù)，針對不同業(yè)務(wù)進(jìn)行技術(shù)選型也是一種很重要的能力

如何提高分布式事務(wù)性能

這兩年來，隨著NoSQL系統(tǒng)、CAP理論和Eventual Consistency的大熱，關(guān)于分布式操作要保證強(qiáng)一致還是弱一致性的討論絡(luò)驛不絕。雙方各執(zhí)一詞，傾向?qū)崿F(xiàn)強(qiáng)一致性的一方認(rèn)為弱一致性滿足不了應(yīng)用開發(fā)的需要，傾向?qū)崿F(xiàn)弱一致性的一方則認(rèn)為保證強(qiáng)一致性將導(dǎo)致系統(tǒng)性能與可伸縮性難以接受。弱一致性能否滿足應(yīng)用開發(fā)的需求這一點(diǎn)由應(yīng)用特征決定，難以一概而論，但強(qiáng)一致性對系統(tǒng)性能、可伸縮性和可用性的影響則是可以作技術(shù)分析的。奇怪的是，找了很久，也沒找到對這一問題的深入分析，決定自己來做一個(gè)。

對于分布式操作，一般來說有以下兩種實(shí)現(xiàn)選擇：

1、 在每個(gè)節(jié)點(diǎn)上使用單獨(dú)的事務(wù)，只實(shí)現(xiàn)弱一致性。

2、 使用2PC保證強(qiáng)一致性。即分布式事務(wù)協(xié)調(diào)者先要求所有參與節(jié)點(diǎn)PREPARE，大家都說PREPARE成功后，再要求所有節(jié)點(diǎn)COMMIT。只要有一個(gè)節(jié)點(diǎn)PREPARE不成功，大家都要回滾。這樣參與者要強(qiáng)制寫兩次日志，協(xié)調(diào)者在決定要COMMIT時(shí)也要強(qiáng)制寫一次日志。

首先，假設(shè)用戶發(fā)起分布式操作的速率為TpS（Transactions per Second），每個(gè)分布式操作平均會(huì)操作K個(gè)節(jié)點(diǎn)。在每個(gè)節(jié)點(diǎn)上，平均要操作RpT（Rows per Transaction）條記錄，而操作每條記錄平均要用時(shí)TpR（Time per Row），這樣在每個(gè)節(jié)點(diǎn)上事務(wù)操作的執(zhí)行時(shí)間為：

TExec=RpT×TpR

另外，設(shè)定以下參數(shù)：

- N：數(shù)據(jù)庫中所有節(jié)點(diǎn)上的總記錄數(shù)

- TCommit：在每個(gè)節(jié)點(diǎn)上PREPARE或COMMIT的時(shí)間，PREPARE和COMMIT的主要工作都是寫相應(yīng)的日志，執(zhí)行時(shí)間接近

對分布式操作性能方面一種常見的認(rèn)識(shí)是若使用2PC，將導(dǎo)致事務(wù)執(zhí)行時(shí)間大為延長，從而導(dǎo)致過高的事務(wù)并發(fā)沖突和死鎖。當(dāng)然，從趨勢上使用2PC自然會(huì)導(dǎo)致并發(fā)沖突和死鎖增長，但是否能滿足應(yīng)用需求，需要定量的來分析。由于死鎖的概率完全取決于沖突概率，以下只分析沖突概率。

對選擇1，即每個(gè)節(jié)點(diǎn)用獨(dú)立事務(wù)時(shí)，用戶發(fā)起的每個(gè)事務(wù)都會(huì)被分成K個(gè)小事務(wù)，這時(shí)系統(tǒng)中的并發(fā)事務(wù)數(shù)是事務(wù)速率與事務(wù)持續(xù)時(shí)間之積，即：

CT_1=TpS×K×(RpT×TpR+TCommit)

當(dāng)某事務(wù)要鎖定并操作某條記錄時(shí)，系統(tǒng)中被其它事務(wù)所鎖定的記錄數(shù)是(CT_1-1)×RpT≈CT_1×RpT。假設(shè)事務(wù)操作的記錄是純隨機(jī)的，則該事務(wù)要鎖定的記錄與其它事務(wù)沖突的概率是(CT_1×RpT)/N。而這個(gè)事務(wù)總共要鎖定RpT條記錄，則該事務(wù)與其它事務(wù)沖突的概率是：

TWait_1=1-(1-(CT_1×RpT)/N )^RpT≈CT_1×RpT^2/N

對選擇2，即使用2PC保證強(qiáng)一致性時(shí)，每個(gè)節(jié)點(diǎn)上需要強(qiáng)制寫兩次日志，在事務(wù)協(xié)調(diào)者上還要強(qiáng)制寫一次PREPARE日志（事務(wù)協(xié)調(diào)者上的COMMIT日志不需要強(qiáng)制寫，這一時(shí)間可以忽略）。系統(tǒng)中的并發(fā)事務(wù)數(shù)是：

CT_2=TpS×((RpT×TpR+2×TCommit)×K+TCommit)

但此時(shí)系統(tǒng)中被其它事務(wù)所鎖定的記錄數(shù)是選擇1的K倍，且事務(wù)要鎖定的記錄數(shù)也是選擇1的K倍，這時(shí)事務(wù)的沖突概率是：

TWait_2≈CT_2×RpT^2×K^2/N

這個(gè)公式比較復(fù)雜，我們先簡化一下，假設(shè)TCommit和TPrepare時(shí)間相對于TExec來說可以忽略，則可以得到有：

TWait_2=TWait_1×K^2

也就是說事務(wù)沖突的概率將會(huì)隨著分布式操作涉及的節(jié)點(diǎn)數(shù)K的平方數(shù)增長。平方數(shù)增長聽起來比較厲害，但實(shí)際上在真實(shí)應(yīng)用中K通常是很小的，絕大多數(shù)情況下等于2。如經(jīng)典的轉(zhuǎn)賬問題，就只涉及兩個(gè)節(jié)點(diǎn)，還有比如建立好友關(guān)系時(shí)也只涉及兩個(gè)節(jié)點(diǎn)。在使用我們分布式數(shù)據(jù)庫的大量應(yīng)用中（總共包含約500張表，上千個(gè)索引，幾千種SQL模式），絕大多數(shù)情況下K為2，很少有3，超過3的更是絕無僅有。因此，如果我們忽略2PC PREPARE和提交的時(shí)間，則使用2PC時(shí)會(huì)導(dǎo)致事務(wù)沖突概率4~9倍的增長。

換一種情況，如果執(zhí)行很快但提交寫日志很慢，即TExec相對于TCommit來說可以忽略，則可以得到：

TWait_2=TWait_1×(2×K+1)/K×K^2

這時(shí)的情況比只考慮執(zhí)行時(shí)間時(shí)差一些，但還是隨著分布式操作涉及的節(jié)點(diǎn)數(shù)K的平方數(shù)增長，只不過從4~9倍變成10~21倍。

真實(shí)的情況一般在這兩者之間，作為估算，可以大致認(rèn)為采用2PC保證強(qiáng)一致性時(shí)將導(dǎo)致事務(wù)沖突概率增加8倍左右。

性能方面還涉及到吞吐率和響應(yīng)時(shí)間。類似的進(jìn)行分析，可以發(fā)現(xiàn)如果TCommit相對于TExec可以忽略，則響應(yīng)時(shí)間不受2PC影響，反之，則2PC會(huì)導(dǎo)致響應(yīng)時(shí)間增加為原來的3倍，平均的估計(jì)可以取增加1倍。對大多數(shù)應(yīng)用，日志提交的吞吐率完全足夠，則事務(wù)吞吐率不受2PC影響，反之，事務(wù)吞吐率會(huì)下降一半。

對大多數(shù)WEB應(yīng)用沖突概率非常低，分布式操作只涉及2~3個(gè)節(jié)點(diǎn)，日志提交的吞吐率完全足夠，則使用2PC可能帶來的影響是事務(wù)沖突與死鎖增加8倍左右，響應(yīng)時(shí)間延長1倍，吞吐率不受影響。這些性能影響應(yīng)該說是完全可以接受的，此時(shí)2PC帶來的強(qiáng)一致性優(yōu)點(diǎn)可以說遠(yuǎn)遠(yuǎn)超過其對性能的影響。

當(dāng)然，以上分析中忽略了很多因素，比如網(wǎng)絡(luò)延時(shí)，比如客戶端在發(fā)起事務(wù)的多個(gè)操作之間還可能休息一會(huì)。加入這些因素后的性能分析會(huì)更復(fù)雜，但這些因素，本質(zhì)上是使事務(wù)的持續(xù)時(shí)間增加，跟是否使用2PC無關(guān)。使用2PC與不使用2PC之間的性能差異比例，與這些因素關(guān)系不大。

但有一個(gè)問題需要注意。如果讓客戶端直接充當(dāng)分布式事務(wù)的協(xié)調(diào)者，由于客戶端上通常不像數(shù)據(jù)庫服務(wù)器那樣配置帶電池的寫緩存，fsync的性能很差，2PC將導(dǎo)致簡單分布式事務(wù)的響應(yīng)時(shí)間增加一個(gè)數(shù)量級，沖突概率更是可能增加兩個(gè)數(shù)量級，事務(wù)提交的吞吐率也可能受到影響。解決方法是部署專職的高性能分布式事務(wù)協(xié)調(diào)者集群，配置高性能的日志存儲(chǔ)設(shè)備如SSD。

基于這一基本的性能分析，還有一些變種：

1、如果分布式操作在各節(jié)點(diǎn)上并行執(zhí)行，可以計(jì)算出沖突概率將是不并行的1/K。這仍比不用2PC串行高K倍，但不再是K的平方倍。比如BigTable中對二級索引和主記錄的修改，就可以并行。

2、如果分布式操作是否沖突只取決于其中一個(gè)節(jié)點(diǎn)，可以計(jì)算出2PC并不會(huì)導(dǎo)致沖突概率顯著增加。符合這一特征的應(yīng)用模式還是BigTable中對主記錄及其所有二級索引的修改，沖不沖突，完全取決于是否更新同一條記錄，跟索引無關(guān)。

根據(jù)這兩點(diǎn)也可以看出，如果用并行的2PC來保證主記錄及其二級索引之間的一致性，其所帶來的性能影響弱于2PC對一般分布式事務(wù)的影響，是完全可以實(shí)用的方案。

對使用2PC分布式事務(wù)的另外一個(gè)比較大的擔(dān)心是如果2PC在PREPARE之后事務(wù)協(xié)調(diào)者崩潰，則參與分布式事務(wù)的各個(gè)節(jié)點(diǎn)只能長時(shí)間的鎖定資源，等待協(xié)調(diào)者復(fù)活后告訴它事務(wù)應(yīng)該提交還是回滾。如果直接讓客戶端直接充當(dāng)分布式事務(wù)的協(xié)調(diào)者，這一問題可能很嚴(yán)重，因?yàn)榭蛻舳硕喽s，崩潰概率高。但如果部署了專職的高性能分布式事務(wù)協(xié)調(diào)者集群，則這一問題基本可以避免。

文章名稱：nosql分布式事務(wù),nosql不支持事務(wù)
文章位置：http://jinyejixie.com/article18/hojsgp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、定制網(wǎng)站、網(wǎng)站收錄、網(wǎng)站內(nèi)鏈、品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)