NewSQL是對一類現代關系型數據庫的統(tǒng)稱，這類數據庫對于一般的OLTP讀寫請求提供可橫向擴展的性能，同時支持事務的ACID保證。這些系統(tǒng)既擁有NoSQL數據庫的擴展性，又保持傳統(tǒng)數據庫的事務特性。NewSQL重新將“應用程序邏輯與數據操作邏輯應該分離”的理念帶回到現代數據庫的世界，這也驗證了歷史的發(fā)展總是呈現出螺旋上升的形式。
公司主營業(yè)務：成都做網站、成都網站建設、移動網站開發(fā)等業(yè)務。幫助企業(yè)客戶真正實現互聯(lián)網宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出肇州免費做網站回饋大家。
在21世紀00年代中，出現了許多數據倉庫系統(tǒng) (如 Vertica，Greeplum 和AsterData)，這些以處理OLAP 請求為設計目標的系統(tǒng)并不在本文定義的NewSQL范圍內。OLAP 數據庫更關注針對海量數據的大型、復雜、只讀的查詢，查詢時間可能持續(xù)秒級、分鐘級甚至更長。
NoSQL的擁躉普遍認為阻礙傳統(tǒng)數據庫橫向擴容、提高可用性的原因在于ACID保證和關系模型，因此NoSQL運動的核心就是放棄事務強一致性以及關系模型，擁抱最終一致性和其它數據模型?(如 key/value，graphs 和Documents)。
兩個最著名的NoSQL數據庫就是Google的BigTable和Amazon的Dynamo，由于二者都未開源，其它組織就開始推出類似的開源替代項目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創(chuàng)業(yè)公司也加入到這場NoSQL運動中，它們不一定是受BigTable和Dynamo的啟發(fā)，但都響應了NoSQL的哲學，其中最出名的就是MongoDB。
在21世紀00年代末，市面上已經有許多供用戶選擇的分布式數據庫產品。使用NoSQL的優(yōu)勢在于應用開發(fā)者可以更關注應用邏輯本身，而非數據庫的擴展性問題；但與此同時許多應用，如金融系統(tǒng)、訂單處理系統(tǒng)，由于無法放棄事務的一致性要求被拒之門外。
一些組織，如Google，已經發(fā)現他們的許多工程師將過多的精力放在處理數據一致性上，這既暴露了數據庫的抽象、又提高了代碼的復雜度，這時候要么選擇回到傳統(tǒng)DBMS時代，用更高的機器配置縱向擴容，要么選擇回到中間件時代，開發(fā)支持分布式事務的中間件。這兩種方案成本都很高，于是NewSQL運動開始醞釀。
NewSQL數據庫設計針對的讀寫事務有以下特點：
1、耗時短。
2、使用索引查詢，涉及少量數據。
3、重復度高，通常使用相同的查詢語句和不同的查詢參考。
也有一些學者認為NewSQL系統(tǒng)是特指實現上使用Lock-free并發(fā)控制技術和share-nothing架構的數據庫。所有我們認為是NewSQL的數據庫系統(tǒng)確實都有這樣的特點。
樓主這個說法很標準，不是不可用，只是不適用。我們看下為什么分布式事務不再適用于微服務架構。
多個微服務應用就構成了分布式系統(tǒng)，由此會帶來固有的復雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進程間通訊機制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當然這并不是什么難事，但相對于單體式應用中通過語言層級的方法或者進程調用，微服務下這種技術顯得更復雜一些。
另外一個關于微服務的挑戰(zhàn)來自于分區(qū)的數據庫架構。商業(yè)交易中同時給多個業(yè)務分主體更新消息很普遍。這種交易對于單體式應用來說很容易，因為只有一個數據庫。在微服務架構應用中，需要更新不同服務所使用的不同的數據庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數據庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。
部署一個微服務應用也很復雜，一個分布式應用只需要簡單在復雜均衡器后面部署各自的服務器就好了。每個應用實例是需要配置諸如數據庫和消息中間件等基礎服務。相對比，一個微服務應用一般由大批服務構成。例如，根據Adrian Cockcroft，Hailo有160個不同服務構成，NetFlix有大約600個服務。每個服務都有多個實例。這就造成許多需要配置、部署、擴展和監(jiān)控的部分，除此之外，你還需要完成一個服務發(fā)現機制，以用來發(fā)現與它通訊服務的地址（包括服務器地址和端口）。傳統(tǒng)的解決問題辦法不能用于解決這么復雜的問題。接續(xù)而來，成功部署一個微服務應用需要開發(fā)者有足夠的控制部署方法，并高度自動化。
總而言之，一句話概括，由于每個微服務實現方式五花八門，當微服務多了情況下，一個服務流程可能會涉及多個服務，如果這些微服務耦合過于強，那必然要確保其事務的一致性，但是這是個及其困難的事情。
在大數據時代，“多種架構支持多類應用”成為數據庫行業(yè)應對大數據的基本思路，數據庫行業(yè)出現互為補充的三大陣營，適用于事務處理應用的OldSQL、適用于數據分析應用的NewSQL和適用于互聯(lián)網應用的NoSQL。但在一些復雜的應用場景中，單一數據庫架構都不能完全滿足應用場景對海量結構化和非結構化數據的存儲管理、復雜分析、關聯(lián)查詢、實時性處理和控制建設成本等多方面的需要，因此不同架構數據庫混合部署應用成為滿足復雜應用的必然選擇。不同架構數據庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個案例對不同架構數據庫的混合應用部署進行介紹。
OldSQL+NewSQL 在數據中心類應用中混合部署
采用OldSQL+NewSQL模式構建數據中心，在充分發(fā)揮OldSQL數據庫的事務處理能力的同時，借助NewSQL在實時性、復雜分析、即席查詢等方面的獨特優(yōu)勢，以及面對海量數據時較強的擴展能力，滿足數據中心對當前“熱”數據事務型處理和海量歷史“冷”數據分析兩方面的需求。OldSQL+NewSQL模式在數據中心類應用中的互補作用體現在，OldSQL彌補了NewSQL不適合事務處理的不足，NewSQL彌補了OldSQL在海量數據存儲能力和處理性能方面的缺陷。
商業(yè)銀行數據中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數據庫滿足各業(yè)務系統(tǒng)數據的歸檔備份和事務型應用，NewSQL MPP數據庫集群對即席查詢、多維分析等應用提供高性能支持，并且通過MPP集群架構實現應對海量數據存儲的擴展能力。
商業(yè)銀行數據中心存儲架構
與傳統(tǒng)的OldSQL模式相比，商業(yè)銀行數據中心采用OldSQL+NewSQL混合搭建模式，數據加載性能提升3倍以上，即席查詢和統(tǒng)計分析性能提升6倍以上。NewSQL MPP的高可擴展性能夠應對新的業(yè)務需求，可隨著數據量的增長采用集群方式構建存儲容量更大的數據中心。
OldSQL+NoSQL 在互聯(lián)網大數據應用中混合部署
在互聯(lián)網大數據應用中采用OldSQL+NoSQL混合模式，能夠很好的解決互聯(lián)網大數據應用對海量結構化和非結構化數據進行存儲和快速處理的需求。在諸如大型電子商務平臺、大型SNS平臺等互聯(lián)網大數據應用場景中，OldSQL在應用中負責高價值密度結構化數據的存儲和事務型處理，NoSQL在應用中負責存儲和處理海量非結構化的數據和低價值密度結構化數據。OldSQL+NoSQL模式在互聯(lián)網大數據應用中的互補作用體現在，OldSQL彌補了NoSQL在ACID特性和復雜關聯(lián)運算方面的不足，NoSQL彌補了OldSQL在海量數據存儲和非結構化數據處理方面的缺陷。
數據魔方是淘寶網的一款數據產品，主要提供行業(yè)數據分析、店鋪數據分析。淘寶數據產品在存儲層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關系型數據庫集群MyFOX和基于HBase的NoSQL存儲集群Prom組成。由于OldSQL強大的語義和關系表達能力，在應用中仍然占據著重要地位，目前存儲在MyFOX中的統(tǒng)計結果數據已經達到10TB，占據著數據魔方總數據量的95%以上。另一方面，NoSQL作為SQL的有益補充，解決了OldSQL數據庫無法解決的全屬性選擇器等問題。
淘寶海量數據產品技術架構
基于OldSQL+NoSQL混合架構的特點，數據魔方目前已經能夠提供壓縮前80TB的數據存儲空間，支持每天4000萬的查詢請求，平均響應時間在28毫秒，足以滿足未來一段時間內的業(yè)務增長需求。
NewSQL+NoSQL 在行業(yè)大數據應用中混合部署
行業(yè)大數據與互聯(lián)網大數據的區(qū)別在于行業(yè)大數據的價值密度更高，并且對結構化數據的實時處理、復雜的多表關聯(lián)分析、即席查詢、數據強一致性等都比互聯(lián)網大數據有更高的要求。行業(yè)大數據應用場景主要是分析類應用，如：電信、金融、政務、能源等行業(yè)的決策輔助、預測預警、統(tǒng)計分析、經營分析等。
在行業(yè)大數據應用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結構化數據分析處理方面的優(yōu)勢，以及NoSQL在非結構數據處理方面的優(yōu)勢，實現NewSQL與NoSQL的功能互補，解決行業(yè)大數據應用對高價值結構化數據的實時處理、復雜的多表關聯(lián)分析、即席查詢、數據強一致性等要求，以及對海量非結構化數據存儲和精確查詢的要求。在應用中，NewSQL承擔高價值密度結構化數據的存儲和分析處理工作，NoSQL承擔存儲和處理海量非結構化數據和不需要關聯(lián)分析、Ad-hoc查詢較少的低價值密度結構化數據的工作。
當前電信運營商在集中化BI系統(tǒng)建設過程中面臨著數據規(guī)模大、數據處理類型多等問題，并且需要應對大量的固定應用，以及占統(tǒng)計總數80%以上的突發(fā)性臨時統(tǒng)計(ad-hoc)需求。在集中化BI系統(tǒng)的建設中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復雜分析、即席查詢等方面處理性能的優(yōu)勢，及NoSQL在非結構化數據處理和海量數據存儲方面的優(yōu)勢，實現高效低成本。
集中化BI系統(tǒng)數據存儲架構
集中化BI系統(tǒng)按照數據類型和處理方式的不同，將結構化數據和非結構化數據分別存儲在不同的系統(tǒng)中：非結構化數據在Hadoop平臺上存儲與處理;結構化、不需要關聯(lián)分析、Ad-hoc查詢較少的數據保存在NoSQL數據庫或Hadoop平臺;結構化、需要關聯(lián)分析或經常ad-hoc查詢的數據，保存在NewSQL MPP數據庫中，短期高價值數據放在高性能平臺，中長期放在低成本產品中。
結語
當前信息化應用的多樣性、復雜性，以及三種數據庫架構各自所具有的優(yōu)勢和局限性，造成任何一種架構的數據庫都不能完全滿足應用需求，因此不同架構數據庫混合使用，從而彌補其他架構的不足成為必然選擇。根據應用場景采用不同架構數據庫進行組合搭配，充分發(fā)揮每種架構數據庫的特點和優(yōu)勢，并且與其他架構數據庫形成互補，完全涵蓋應用需求，保證數據資源的最優(yōu)化利用，將成為未來一段時期內信息化應用主要采用的解決方式。
目前在國內市場上，OldSQL主要為Oracle、IBM等國外數據庫廠商所壟斷，達夢、金倉等國產廠商仍處于追趕狀態(tài);南大通用憑借國產新型數據庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強;NoSQL方面用戶則大多采用Hadoop開源方案。
像MongoDB, Cassandra, HBase, DynamoDB, 和
Riak這些NoSQL缺乏傳統(tǒng)的原子事務機制，所謂原子事務機制是可以保證一系列寫操作要么全部完成，要么全部不會完成，不會發(fā)生只完成一系列中一兩個
寫操作;因為數據庫不提供這種事務機制支持，開發(fā)者需要自己編寫代碼來確保一系列寫操作的事務機制，比較復雜和測試。
這些NoSQL數據庫不提供事務機制原因在于其分布式特點，一系列寫操作中訪問的數據可能位于不同的分區(qū)服務器，這樣的事務就變成分布式事務，在分
布式事務中實現原子性需要彼此協(xié)調，而協(xié)調是耗費時間的，每臺機器在一個大事務過程中必須依次確認，這就需要一種協(xié)議確保一個事務中沒有任何一臺機器寫操
作失敗。
這種協(xié)調是昂貴的，會增加延遲時間，關鍵問題是，當協(xié)調沒有完成時，其他操作是不能讀取事務中寫操作結果的，這是因為事務的all-or-
nothing原理導致，萬一協(xié)調過程發(fā)現某個寫操作不能完成，那么需要將其他寫操作成功的進行回滾。針對分布式事務的分布式協(xié)調對整體數據庫性能有嚴重
影響，不只是吞吐量還包括延遲時間，這樣大部分NoSQL數據庫因為性能問題就選擇不提供分布式事務。
MongoDB, Riak, HBase, 和 Cassandra提供基于單一鍵的事務，這是因為所有信息都和一個鍵key有關，這個鍵是存儲在單個服務器上，這樣基于單鍵的事務不會帶來復雜的分布式協(xié)調。
那么看來擴展性性能和分布式事務是一對矛盾，總要有取舍?實際上是不完全是，現在完全有可能提供高擴展的性能同時提供分布式原子事務。
FIT是這樣一個在分布式系統(tǒng)提供原子事務的策略，在fairness公平性, isolation隔離性, 和throughput吞吐量(簡稱FIT)可以權衡。
一個支持分布式事務的可伸縮分布式系統(tǒng)能夠完成這三個屬性中兩個，公平是事務之間不會相互影響造成延遲;隔離性提供一種幻覺好像整個數據庫只有它自
己一個事務，隔離性保證當任何同時發(fā)生的事務發(fā)生沖突時，能夠保證彼此能看到彼此的寫操作結果，因此減輕了程序員為避免事務讀寫沖突的強邏輯推理要求;吞
吐量是指每單元時間數據庫能夠并發(fā)處理多少事務。
FIT是如下進行權衡：
保證公平性fairness 和隔離性isolation, 但是犧牲吞吐量
保證公平性fairness和吞吐量, 犧牲隔離性isolation
保證隔離性isolation和吞吐量throughput, 但是犧牲公平性fairness.
犧牲公平性：放棄公平性，數據庫能有更多機會降低分布式事務的成本，主要成本是分布式協(xié)調帶來的，也就是說，不需要在每個事務過程內對每個機器都依
次確認事務完成，這樣排隊式的確認commit事務是很浪費時間的，放棄公平性，意味著可以在事務外面進行協(xié)調，這樣就只是增加了協(xié)調時間，不會增加互相
沖突事務因為彼此沖突而不能運行所耽擱的時間，當系統(tǒng)不需要公平性時，需要根據事務的優(yōu)先級或延遲等標準進行指定先后執(zhí)行順序，這樣就能夠獲得很好的吞吐
量。
G-Store是一種放棄公平性的 Isolation-Throughput
的分布式key-value存儲，支持多鍵事務(multi-key transactions)，MongoDB 和
HBase在鍵key在同樣分區(qū)上也支持多鍵事務，但是不支持跨分區(qū)的事務。
總之：傳統(tǒng)分布式事務性能不佳的原因是確保原子性(分布式協(xié)調)和隔離性同時重疊，創(chuàng)建一個高吞吐量分布式事務的關鍵是分離這兩種關注，這種分離原
子性和隔離性的視角將導致兩種類型的系統(tǒng)，第一種選擇是弱隔離性能讓沖突事務并行執(zhí)行和確認提交;第二個選擇重新排序原子性和隔離性機制保證它們不會某個
時間重疊，這是一種放棄公平的事務執(zhí)行，所謂放棄公平就是不再同時照顧原子性和隔離性了，有所傾斜，放棄高標準道德要求就會帶來高自由高效率。
1、什么是分布式事務
分布式事務就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。以上是百度百科的解釋，簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬于不同的應用，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。本質上來說，分布式事務就是為了保證不同數據庫的數據一致性。
2、分布式事務的產生的原因
2.1、數據庫分庫分表
當數據庫單表一年產生的數據超過1000W，那么就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以后有空詳細說，簡單的說就是原來的一個數據庫變成了多個數據庫。這時候，如果一個操作既訪問01庫，又訪問02庫，而且要保證數據的一致性，那么就要用到分布式事務。
2.2、應用SOA化
所謂的SOA化，就是業(yè)務的服務化。比如原來單機支撐了整個電商網站，現在對整個網站進行拆解，分離出了訂單中心、用戶中心、庫存中心。對于訂單中心，有專門的數據庫存儲訂單信息，用戶中心也有專門的數據庫存儲用戶信息，庫存中心也會有專門的數據庫存儲庫存信息。這時候如果要同時對訂單和庫存進行操作，那么就會涉及到訂單數據庫和庫存數據庫，為了保證數據一致性，就需要用到分布式事務。
以上兩種情況表象不同，但是本質相同，都是因為要操作的數據庫變多了！
3、事務的ACID特性
3.1、原子性（A）
所謂的原子性就是說，在整個事務中的所有操作，要么全部完成，要么全部不做，沒有中間狀態(tài)。對于事務在執(zhí)行中發(fā)生錯誤，所有的操作都會被回滾，整個事務就像從沒被執(zhí)行過一樣。
3.2、一致性（C）
事務的執(zhí)行必須保證系統(tǒng)的一致性，就拿轉賬為例，A有500元，B有300元，如果在一個事務里A成功轉給B50元，那么不管并發(fā)多少，不管發(fā)生什么，只要事務執(zhí)行成功了，那么最后A賬戶一定是450元，B賬戶一定是350元。
3.3、隔離性（I）
所謂的隔離性就是說，事務與事務之間不會互相影響，一個事務的中間狀態(tài)不會被其他事務感知。
3.4、持久性（D）
所謂的持久性，就是說一單事務完成了，那么事務對數據所做的變更就完全保存在了數據庫中，即使發(fā)生停電，系統(tǒng)宕機也是如此。
4、分布式事務的應用場景
4.1、支付
最經典的場景就是支付了，一筆支付，是對買家賬戶進行扣款，同時對賣家賬戶進行加錢，這些操作必須在一個事務里執(zhí)行，要么全部成功，要么全部失敗。而對于買家賬戶屬于買家中心，對應的是買家數據庫，而賣家賬戶屬于賣家中心，對應的是賣家數據庫，對不同數據庫的操作必然需要引入分布式事務。
4.2、在線下單
買家在電商平臺下單，往往會涉及到兩個動作，一個是扣庫存，第二個是更新訂單狀態(tài)，庫存和訂單一般屬于不同的數據庫，需要使用分布式事務保證數據一致性。
5、常見的分布式事務解決方案
5.1、基于XA協(xié)議的兩階段提交
XA是一個分布式事務協(xié)議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數據庫實現，比如Oracle、DB2這些商業(yè)數據庫都實現了XA接口，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。XA實現分布式事務的原理如下：
總的來說，XA協(xié)議比較簡單，而且一旦商業(yè)數據庫實現了XA協(xié)議，使用分布式事務的成本也比較低。但是，XA也有致命的缺點，那就是性能不理想，特別是在交易下單鏈路，往往并發(fā)量很高，XA無法滿足高并發(fā)場景。XA目前在商業(yè)數據庫支持的比較理想，在mysql數據庫中支持的不太理想，mysql的XA實現，沒有記錄prepare階段日志，主備切換回導致主庫與備庫數據不一致。許多nosql也沒有支持XA，這讓XA的應用場景變得非常狹隘。
5.2、消息事務+最終一致性
所謂的消息事務就是基于消息中間件的兩階段提交，本質上是對消息中間件的一種特殊利用，它是將本地事務和發(fā)消息放在了一個分布式事務里，保證要么本地操作成功成功并且對外發(fā)消息成功，要么兩者都失敗，開源的RocketMQ就支持這一特性，具體原理如下：
1、A系統(tǒng)向消息中間件發(fā)送一條預備消息
2、消息中間件保存預備消息并返回成功
3、A執(zhí)行本地事務
4、A發(fā)送提交消息給消息中間件
通過以上4步完成了一個消息事務。對于以上的4個步驟，每個步驟都可能產生錯誤，下面一一分析：
步驟一出錯，則整個事務失敗，不會執(zhí)行A的本地操作步驟二出錯，則整個事務失敗，不會執(zhí)行A的本地操作步驟三出錯，這時候需要回滾預備消息，怎么回滾？答案是A系統(tǒng)實現一個消息中間件的回調接口，消息中間件會去不斷執(zhí)行回調接口，檢查A事務執(zhí)行是否執(zhí)行成功，如果失敗則回滾預備消息步驟四出錯，這時候A的本地事務是成功的，那么消息中間件要回滾A嗎？答案是不需要，其實通過回調接口，消息中間件能夠檢查到A執(zhí)行成功了，這時候其實不需要A發(fā)提交消息了，消息中間件可以自己對消息進行提交，從而完成整個消息事務基于消息中間件的兩階段提交往往用在高并發(fā)場景下，將一個分布式事務拆成一個消息事務（A系統(tǒng)的本地操作+發(fā)消息）+B系統(tǒng)的本地操作，其中B系統(tǒng)的操作由消息驅動，只要消息事務成功，那么A操作一定成功，消息也一定發(fā)出來了，這時候B會收到消息去執(zhí)行本地操作，如果本地操作失敗，消息會重投，直到B操作成功，這樣就變相地實現了A與B的分布式事務。原理如下：
雖然上面的方案能夠完成A和B的操作，但是A和B并不是嚴格一致的，而是最終一致的，我們在這里犧牲了一致性，換來了性能的大幅度提升。當然，這種玩法也是有風險的，如果B一直執(zhí)行不成功，那么一致性會被破壞，具體要不要玩，還是得看業(yè)務能夠承擔多少風險。
5.3、TCC編程模式
所謂的TCC編程模式，也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業(yè)務邏輯分為三塊：Try、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態(tài)，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存?？傊琓CC就是通過代碼人為實現了兩階段提交，不同的業(yè)務場景所寫的代碼都不一樣，復雜度也不一樣，因此，這種模式并不能很好地被復用。
6、總結
分布式事務，本質上是對多個數據庫的事務進行統(tǒng)一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務，部分控制就是各種變種的兩階段提交，包括上面提到的消息事務+最終一致性、TCC模式，而完全控制就是完全實現兩階段提交。部分控制的好處是并發(fā)量和性能很好，缺點是數據一致性減弱了，完全控制則是犧牲了性能，保障了一致性，具體用哪種方式，最終還是取決于業(yè)務場景。作為技術人員，一定不能忘了技術是為業(yè)務服務的，不要為了技術而技術，針對不同業(yè)務進行技術選型也是一種很重要的能力
這兩年來，隨著NoSQL系統(tǒng)、CAP理論和Eventual Consistency的大熱，關于分布式操作要保證強一致還是弱一致性的討論絡驛不絕。雙方各執(zhí)一詞，傾向實現強一致性的一方認為弱一致性滿足不了應用開發(fā)的需要，傾向實現弱一致性的一方則認為保證強一致性將導致系統(tǒng)性能與可伸縮性難以接受。弱一致性能否滿足應用開發(fā)的需求這一點由應用特征決定，難以一概而論，但強一致性對系統(tǒng)性能、可伸縮性和可用性的影響則是可以作技術分析的。奇怪的是，找了很久，也沒找到對這一問題的深入分析，決定自己來做一個。
對于分布式操作，一般來說有以下兩種實現選擇：
1、 在每個節(jié)點上使用單獨的事務，只實現弱一致性。
2、 使用2PC保證強一致性。即分布式事務協(xié)調者先要求所有參與節(jié)點PREPARE，大家都說PREPARE成功后，再要求所有節(jié)點COMMIT。只要有一個節(jié)點PREPARE不成功，大家都要回滾。這樣參與者要強制寫兩次日志，協(xié)調者在決定要COMMIT時也要強制寫一次日志。
首先，假設用戶發(fā)起分布式操作的速率為TpS（Transactions per Second），每個分布式操作平均會操作K個節(jié)點。在每個節(jié)點上，平均要操作RpT（Rows per Transaction）條記錄，而操作每條記錄平均要用時TpR（Time per Row），這樣在每個節(jié)點上事務操作的執(zhí)行時間為：
TExec=RpT×TpR
另外，設定以下參數：
- N：數據庫中所有節(jié)點上的總記錄數
- TCommit：在每個節(jié)點上PREPARE或COMMIT的時間，PREPARE和COMMIT的主要工作都是寫相應的日志，執(zhí)行時間接近
對分布式操作性能方面一種常見的認識是若使用2PC，將導致事務執(zhí)行時間大為延長，從而導致過高的事務并發(fā)沖突和死鎖。當然，從趨勢上使用2PC自然會導致并發(fā)沖突和死鎖增長，但是否能滿足應用需求，需要定量的來分析。由于死鎖的概率完全取決于沖突概率，以下只分析沖突概率。
對選擇1，即每個節(jié)點用獨立事務時，用戶發(fā)起的每個事務都會被分成K個小事務，這時系統(tǒng)中的并發(fā)事務數是事務速率與事務持續(xù)時間之積，即：
CT_1=TpS×K×(RpT×TpR+TCommit)
當某事務要鎖定并操作某條記錄時，系統(tǒng)中被其它事務所鎖定的記錄數是(CT_1-1)×RpT≈CT_1×RpT。假設事務操作的記錄是純隨機的，則該事務要鎖定的記錄與其它事務沖突的概率是(CT_1×RpT)/N。而這個事務總共要鎖定RpT條記錄，則該事務與其它事務沖突的概率是：
TWait_1=1-(1-(CT_1×RpT)/N )^RpT≈CT_1×RpT^2/N
對選擇2，即使用2PC保證強一致性時，每個節(jié)點上需要強制寫兩次日志，在事務協(xié)調者上還要強制寫一次PREPARE日志（事務協(xié)調者上的COMMIT日志不需要強制寫，這一時間可以忽略）。系統(tǒng)中的并發(fā)事務數是：
CT_2=TpS×((RpT×TpR+2×TCommit)×K+TCommit)
但此時系統(tǒng)中被其它事務所鎖定的記錄數是選擇1的K倍，且事務要鎖定的記錄數也是選擇1的K倍，這時事務的沖突概率是：
TWait_2≈CT_2×RpT^2×K^2/N
這個公式比較復雜，我們先簡化一下，假設TCommit和TPrepare時間相對于TExec來說可以忽略，則可以得到有：
TWait_2=TWait_1×K^2
也就是說事務沖突的概率將會隨著分布式操作涉及的節(jié)點數K的平方數增長。平方數增長聽起來比較厲害，但實際上在真實應用中K通常是很小的，絕大多數情況下等于2。如經典的轉賬問題，就只涉及兩個節(jié)點，還有比如建立好友關系時也只涉及兩個節(jié)點。在使用我們分布式數據庫的大量應用中（總共包含約500張表，上千個索引，幾千種SQL模式），絕大多數情況下K為2，很少有3，超過3的更是絕無僅有。因此，如果我們忽略2PC PREPARE和提交的時間，則使用2PC時會導致事務沖突概率4~9倍的增長。
換一種情況，如果執(zhí)行很快但提交寫日志很慢，即TExec相對于TCommit來說可以忽略，則可以得到：
TWait_2=TWait_1×(2×K+1)/K×K^2
這時的情況比只考慮執(zhí)行時間時差一些，但還是隨著分布式操作涉及的節(jié)點數K的平方數增長，只不過從4~9倍變成10~21倍。
真實的情況一般在這兩者之間，作為估算，可以大致認為采用2PC保證強一致性時將導致事務沖突概率增加8倍左右。
性能方面還涉及到吞吐率和響應時間。類似的進行分析，可以發(fā)現如果TCommit相對于TExec可以忽略，則響應時間不受2PC影響，反之，則2PC會導致響應時間增加為原來的3倍，平均的估計可以取增加1倍。對大多數應用，日志提交的吞吐率完全足夠，則事務吞吐率不受2PC影響，反之，事務吞吐率會下降一半。
對大多數WEB應用沖突概率非常低，分布式操作只涉及2~3個節(jié)點，日志提交的吞吐率完全足夠，則使用2PC可能帶來的影響是事務沖突與死鎖增加8倍左右，響應時間延長1倍，吞吐率不受影響。這些性能影響應該說是完全可以接受的，此時2PC帶來的強一致性優(yōu)點可以說遠遠超過其對性能的影響。
當然，以上分析中忽略了很多因素，比如網絡延時，比如客戶端在發(fā)起事務的多個操作之間還可能休息一會。加入這些因素后的性能分析會更復雜，但這些因素，本質上是使事務的持續(xù)時間增加，跟是否使用2PC無關。使用2PC與不使用2PC之間的性能差異比例，與這些因素關系不大。
但有一個問題需要注意。如果讓客戶端直接充當分布式事務的協(xié)調者，由于客戶端上通常不像數據庫服務器那樣配置帶電池的寫緩存，fsync的性能很差，2PC將導致簡單分布式事務的響應時間增加一個數量級，沖突概率更是可能增加兩個數量級，事務提交的吞吐率也可能受到影響。解決方法是部署專職的高性能分布式事務協(xié)調者集群，配置高性能的日志存儲設備如SSD。
基于這一基本的性能分析，還有一些變種：
1、如果分布式操作在各節(jié)點上并行執(zhí)行，可以計算出沖突概率將是不并行的1/K。這仍比不用2PC串行高K倍，但不再是K的平方倍。比如BigTable中對二級索引和主記錄的修改，就可以并行。
2、如果分布式操作是否沖突只取決于其中一個節(jié)點，可以計算出2PC并不會導致沖突概率顯著增加。符合這一特征的應用模式還是BigTable中對主記錄及其所有二級索引的修改，沖不沖突，完全取決于是否更新同一條記錄，跟索引無關。
根據這兩點也可以看出，如果用并行的2PC來保證主記錄及其二級索引之間的一致性，其所帶來的性能影響弱于2PC對一般分布式事務的影響，是完全可以實用的方案。
對使用2PC分布式事務的另外一個比較大的擔心是如果2PC在PREPARE之后事務協(xié)調者崩潰，則參與分布式事務的各個節(jié)點只能長時間的鎖定資源，等待協(xié)調者復活后告訴它事務應該提交還是回滾。如果直接讓客戶端直接充當分布式事務的協(xié)調者，這一問題可能很嚴重，因為客戶端多而雜，崩潰概率高。但如果部署了專職的高性能分布式事務協(xié)調者集群，則這一問題基本可以避免。
重慶分公司
重慶分公司
