雲時代的分佈式數據庫：阿里分佈式數據庫服務DRDS

發表於 2015-07-15 21:47| 10943次閱讀| 來源《程序員》雜誌| 27 條評論| 做者王晶昱

《程序員》雜誌 數據庫 DRDS 分佈式 沈詢

摘要：伴隨着系統性能、成本及擴展性的新時代須要，以HBase、MongoDB爲表明的NoSQL數據庫和以阿里DRDS、VoltDB、ScaleBase爲表明的分佈式NewSQL數據庫如雨後春筍般不斷涌現出來。本文詳細介紹了阿里分佈式數據庫服務DRDS。

隨着互聯網時代的到來，計算機要管理的數據量呈指數級別地飛速上漲，而咱們卻徹底沒法對用戶數作出準確預估。咱們的系統所須要支持的用戶 數，極可能在短短的一個月內忽然爆發式地增加幾千倍，數據也極可能快速地從原來的幾百GB飛速上漲到了幾百個TB。若是在這爆發的關鍵時刻，系統不穩定或 沒法訪問，那麼對於業務將會是毀滅性的打擊。

伴隨着這種對於系統性能、成本以及擴展性的新須要，以HBase、MongoDB爲表明的NoSQL數據庫和以阿里DRDS、VoltDB、ScaleBase爲表明的分佈式NewSQL數據庫如雨後春筍般不斷涌現出來。

本文將會介紹阿里DRDS的技術理念、發展歷程、技術特性等內容。

DRDS設計理念

從20世紀70年代關係數據庫創立開始，其實你們在數據庫上的追求就從未發生過變化：更快的存取數據，能夠按需擴縮以承載更大的訪問量和更大的數據量，開發容易，硬件成本低，咱們能夠把這叫作數據庫領域的聖盃。

爲 了支撐更大的訪問量和數據量，咱們必然須要分佈式數據庫系統，然而分佈式系統又必然會面對強一致性所帶來的延遲提升的問題，由於網絡通訊自己比單機內通訊 代價高不少，這種通訊的代價就會直接增長系統單次提交的延遲。延遲提升會致使數據庫鎖持有時間變長，使得高衝突條件下分佈式事務的性能不升反降（這個具體 能夠了解一下Amdahl定律），甚至性能距離單機數據庫都還有明顯的差距。

從上面的說明，咱們能夠發現，問題的關鍵並非分佈式事務作不 出來，而是作出來了卻由於性能太差而沒有什麼卵用。數據庫領域的高手們努力了40年，但至今仍然沒有人可以很好地解決這個問題，Google Spanner的開發負責人就常常在他的Blog上談論延遲的問題，相信也是飽受這個問題的困擾。

面對這個難題，傳統的關係數據庫選擇了放 棄分佈式的方案，由於在20世紀70~80年代，咱們的數據庫主要被用來處理企業內的各種數據，面對的用戶不過幾千人，而數據量最多也就是TB級別。用單 臺機器來處理事務，用個磁盤陣列處理一下磁盤容量不夠的問題，基本上就能解決一切問題了。

然而，信息化和互聯網的浪潮改變了這一切，咱們突 然發現，咱們服務的對象發生了根本性變化，從原來的幾千人，變成了如今的幾億人，數據量也從TB級別到了PB級別甚至更多。存在單點的單機系統不管如何努 力，都會面對系統處理能力的天花板。原來的這條路，看起來是走不下去了，咱們必須想辦法換一條路來走。

但是，分佈式數據庫所面對的強一致性難題卻像一座高山，人們努力了無數個日日夜夜，但能翻越這座山的日子看來仍然遙遙無期。

於 是，有一羣人認爲，強一致性這件事看來不怎麼靠譜，那完全繞開這個問題是否是個更好的選擇？他們發現確實有那麼一些場景是不須要強一致事務的，甚至連 SQL均可以不要，最典型的就是日誌流水的記錄與分析這類場景。而去掉了事務和SQL，接口簡單了，性能就更容易獲得提高，擴展性也更容易實現，這就是 NoSQL系統的起源。

雖然NoSQL解決了性能和擴展性問題，但這種繞開問題的方法給用戶帶來了不少困擾，系統的開發成本也大大提高。這 時候就有另一羣人，他們以爲用戶須要SQL，以爲用戶也須要事務，問題的關鍵在於咱們要努力地往聖盃的方向不斷前進。在保持系統的擴展性和性能的前提 下，付出儘量小的代價來知足業務對數據庫的須要。這就是NewSQL這個理念的由來。

DRDS也是一個NewSQL的系統，它與ScaleBase、VoltDB等系統相似，都但願可以找到一條既能保持系統的高擴展性和高性能，又能儘量保持傳統數據庫的ACID事務和SQL特性的分佈式數據庫系統。

DRDS發展歷程

在一開始，TDDL的主要功能就是作數據庫切分，一個或一組SQL請求提交到TDDL，TDDL進行規則運算後得知SQL應該被分發到哪一個機器，直接將SQL轉發到對應機器便可（如圖1）。

圖1 TDDL數據庫切分

開始的時候，這種簡單的路由策略可以知足用戶的須要，咱們開始的那些應用，就是經過這樣很是簡單的方式完成了他全部的應用請求。咱們也認爲，這種方案簡單可靠，已經足夠好用了。

然而，當咱們服務的應用從十幾個增加到幾百個的時候，大量的中小應用加入，你們紛紛表示，原來的方案限制太大，不少應用其實只是但願作個讀寫分離，但願能有更好的SQL兼容性。

因而，咱們作了第一次重大升級，在此次升級裏，咱們提出了一個重要的概念就是三層架構，Matrix對應數據庫切分場景，對SQL有必定限制，Group對應讀寫分離和高可用場景，對SQL幾乎沒有限制。如圖2所示。

圖2 數據庫升級爲三層架構

這 種作法馬上獲得了你們的承認，TDDL所提供的讀寫分離、分庫分表等核心功能，也成爲了阿里集團內數據庫領域的標配組件，在阿里的幾乎全部應用上都有應 用。最爲可貴的是，這些功能從上線後，到如今已經經歷了多年雙11的嚴酷考驗，從未出現過嚴重故障（p0、p1級別故障屬於嚴重故障）。數據庫體系做爲整 個應用系統的重中之重，能作到這件事，真是很是不容易。

隨着核心功能的穩定，自2010年開始，咱們集中所有精力開始關注TDDL後端運維 系統的完善與改進性工做。在DBA團隊的給力配合下，圍繞着TDDL，咱們成功作到了在線數據動態擴縮、異步索引等關鍵特徵，同時也比較成功地構建了一整 套分佈式數據庫服務管控體系，用戶基本上能夠徹底自助地完成整套數據庫環境的搭建與初始化工做。

大概是2012年，咱們在阿里雲團隊的支持下，開始嘗試將TDDL這套體系輸出到阿里雲上，也有了個新的名字：阿里分佈式數據庫服務（DRDS），但願可以用咱們的技術服務好更多的人。

不 過當咱們滿懷自信地把本身的軟件拿到雲上的時候，卻發現咱們的軟件距離用戶的要求差距很大。在內部由於有DBA的同窗們幫助進行SQL review，因此SQL的複雜度都是可控的。然而到了雲上，看了各類渠道提過來的兼容性需求，咱們常常是不自覺地發出這樣的感嘆：「啊？原來這種語法 MySQL也是能夠支持的？」

因而，咱們又進行了架構升級，此次是以兼容性爲核心目標的系統升級工做，但願可以在分佈式場景下支持各種複雜的SQL，同時也將阿里這麼多年來在分佈式事務上的積累都帶到了DRDS裏面。

此次架構升級，咱們的投入前所未有，用了三年多才將整個系統落地完成。咱們先在內部以咱們本身的業務做爲首批用戶上線，通過了內部幾百個應用的嚴酷考驗之後，咱們纔敢拿到雲上，給到咱們的最終用戶使用。

目前，咱們正在將TDDL中更多的積累輸出到雲上，同時也努力優化咱們的用戶界面。PS：其實用戶界面優化對咱們這種專一於高性能後端技術的團隊來講，纔是最大的技術挑戰，連我也去學了AngularJS，參與了用戶UI編。

DRDS主要功能介紹

發展歷史看完了，下面就由我來介紹一下目前咱們已經輸出到雲上的主要功能。

分佈式SQL執行引擎

分佈式SQL引擎主要的目的，就是實現與單機數據庫SQL引擎的徹底兼容。目前咱們的SQL引擎可以作到與MySQL的SQL引擎全兼容，包括各種join和各種複雜函數等。他主要包含SQL解析、優化、執行和合並四個流程，如圖3中綠色部分。

圖3 SQL引擎實現的主要流程

雖 然SQL是兼容的，可是分佈式SQL執行算法與單機SQL的執行算法卻徹底不一樣，緣由也很簡單，網絡通訊的延遲比單機內通訊的延遲大得多。舉個例子說明一 下，咱們有份文件要從一張紙A上謄寫到另一張紙B上，單機系統就比如兩張紙都在同一個辦公室裏，而分佈式數據庫則就像是一張紙在北京，一張紙在杭州。

自 然地，若是兩張紙在同一個辦公室，由於傳輸距離近，逐行謄寫的效率是能夠接受的。而若是距離是北京到杭州，用逐行謄寫的方式，就馬上顯得代價過高了，咱們 總不能看一行，就打個「飛的」去杭州寫下來吧。在這種狀況下，仍是把紙A上的信息拍個照片，【一整批的】帶到杭州去處理，明顯更簡單一些。這就是分佈式數 據庫特別強調吞吐調優的緣由，只要是涉及到跨機的全部查詢，都必須儘量的積攢一批後一塊兒發送，以減小系統延遲提升帶來的不良影響。

按需數據庫集羣平滑擴縮

DRDS容許應用按需將新的單機存儲加入或移出集羣，DRDS則可以保證應用在遷移流程中實現不停機擴容縮容。

圖4 DRDS按需進行平滑擴縮

在內部的數據庫使用實踐中，這個功能的一個最重要應用場景就是雙11了。在雙11以前，咱們會將大批的機器加入到咱們的數據庫集羣中，抗過了雙11，這批機器就會下線。

當 DRDS來到雲上，咱們發現雙11其實不只僅只影響阿里內部的系統。在下游的各種電商輔助性系統其實也面對巨大壓力。在雙11前5天，網聚寶的熊總就找到 我說，擔憂撐不過雙11的流量，怕系統掛。因而咱們就給他介紹了這個自動擴容的功能怎麼用，他買了一個月的數據庫，掛接在DRDS上。數據庫能力馬上翻 倍，輕鬆抗過了雙11，也算是我印象比較深入的一個案例了。

由於咱們徹底沒法預測在什麼時間點系統會有爆發性的增加，而若是在這時候系統由於技術緣由不能使用，就會給整個業務帶來毀滅性的影響，風口一旦錯過，就追悔莫及了。我想這就是雲計算特別強調可擴展能力的緣由吧。

小表廣播

小表廣播也是咱們在分佈式數據庫領域內最經常使用的工具之一，他的核心目的其實都是一個——儘量讓查詢只發生在單機。

讓咱們用一個例子來講明，小表廣播的通常使用場景。

圖5 小表廣播場景

圖 5中，若是我想知道買家id等於0的用戶在商城裏面買了哪些商品，咱們通常會先將這兩個表join起來，而後再用where平臺名=」商城」 and buyerID = 0找到符合要求的數據。然而這種join的方式，會致使大量的針對左表的網絡I/O。若是要取出的數據量比較大，系統延遲會明顯上升。

這時候，爲了提高性能，咱們就必需要減小跨機join的網絡代價。咱們比較推薦應用作以下處理，將左表複製到右表的每個庫上。這樣，join操做就由分佈式join一下變回到本地join，系統的性能就有很大的提高了，如圖6所示。

圖6

分佈式事務套件

在阿里巴巴的業務體系中存在很是多須要事務類的場景，下單減庫存，帳務，都是事務場景最集中的部分。

而咱們處理事務的方法卻和傳統應用處理事務的方案不大同樣，咱們很是強調事務的最終一致性和異步化。利用這種方式，可以極大地下降分佈式系統中鎖持有的時間，從而極大地提高系統性能。

圖7 DRDS分佈式事務解決套件

這種處理機制，是咱們分佈式事務可以以極低成本大量運行的最核心法門。在DRDS平臺內，咱們將這些方案產品化，爲了DRDS的分佈式事務解決套件。

利用他們，可以讓你以比較低的成本，實現低延遲，高吞吐的分佈式事務場景。

DRDS的將來

阿里分佈式數據庫服務DRDS上線至今，你們對這款產品的熱情超出了咱們的預期，短短半年內已經有幾千個申請。

儘管還在公測期，可是你們就已經把關係到身家性命的寶貴在線數據業務放到了DRDS上，我可以感覺到這份沉甸甸的信賴，也不想辜負這份信賴。

通過阿里內部幾千個應用的不斷歷練，DRDS已經積累出一套強大的分佈式SQL執行引擎和和一整套分佈式事務套件。

我也相信，這些積累可以讓用戶在基本保持單機數據庫的使用習慣的前提下，享受到分佈式數據庫高性能可擴展的好處。

在平時的DRDS支持過程當中，我面對最多的問題就是，DRDS能不可以在不改變任何原有業務邏輯和代碼的前提下，實現可自由伸縮和擴展呢？十分惋惜的是，關係數據庫發展至今，尚未找到既能保留傳統數據庫一切特性，又能實現高性能可擴展數據庫的方法。

然而，雖不能至，吾心嚮往之！咱們會以「可擴展，高性能」爲產品核心，堅決地走在追尋聖盃的路上，並堅信最終咱們必定可以找尋到它神聖的所在。

做者：王晶昱

簡介：王晶昱，花名沈詢，阿里巴巴資深技術專家。目前主要負責阿里的分佈式數據庫DRDS（TDDL）和阿里的分佈式消息服務ONS（RocketMQ/Notify）兩個系統。