OceanBase簡介

　　OceanBase是阿里集團研發的可擴展的關系數據庫，實現了數千億條記錄、數百TB數據上的跨行跨表事務，截止到2012年8月，支持了收藏夾、直通車報表、天貓評價等OLTP和OLAP在線業務，線上數據量已經超過一千億條。

　　從模塊劃分的角度看，OceanBase可以劃分為四個模塊：主控服務器RootServer、更新服務器UpdateServer、基線數據服務器ChunkServer以及合并服務器MergeServer。OceanBase系統內部按照時間線將數據劃分為基線數據和增量數據，基線數據是只讀的，所有的修改更新到增量數據中，系統內部通過合并操作定期將增量數據融合到基線數據中。

OceanBase背景分析

　　淘寶收藏夾是淘寶線上應用之一，淘寶用戶在其中保存自己感興趣的寶貝（即商品，此外用戶也可以收藏感興趣的店鋪）以便下次快速訪問、對比和購買等，用戶可以展示和編輯（添加/刪除）自己的收藏。淘寶收藏夾數據庫包含了收藏info表（一條一條的收藏信息）和收藏item表（被收藏的寶貝和店鋪）等：

●收藏info表保存收藏信息條目，數百億條。
●收藏item表保存收藏的寶貝和店鋪的詳細信息，數十億條。
●熱門寶貝可能被多達數十萬買家收藏。

●每個用戶可以收藏千個寶貝。

●寶貝的價格、收藏人氣等信息隨時變化。

　　如果用戶選擇按寶貝價格排序后展示，那么數據庫需要從收藏item表中讀取收藏的寶貝的價格等最新信息，然后進行排序處理。如果用戶的收藏條目比較多（例如4000條），那么查詢對應的item的時間會較長：假設如果平均每條item查詢時間是5ms，則4000條的查詢時間可能達到20s，如果真如此，則用戶體驗會很差。
如果把收藏的寶貝的詳細信息實時冗余到收藏info表，則上述查詢收藏item表的操作就不再需要了。但是，由于許多熱門商品可能有幾千到幾十萬人收藏，這些熱門商品的價格等信息的變動可能導致收藏info表的大量修改，并壓垮數據庫。

OceanBase設計思路

　　OceanBase的目標是支持數百TB的數據量以及數十萬TPS、數百萬QPS的訪問量，無論是數據量還是訪問量，即使采用非常昂貴的小型機甚至是大型機，單臺關系數據庫系統都無法承受。
一種常見的做法是根據業務特點對數據庫進行水平拆分，通常的做法是根據某個業務字段（通常取用戶編號，user_id）哈希后取模，根據取模的結果將數據分布到不同的數據庫服務器上，客戶端請求通過數據庫中間層路由到不同的分區。這種方式目前還存在一定的弊端，如下所示：
●數據和負載增加后添加機器的操作比較復雜，往往需要人工介入；
●有些范圍查詢需要訪問幾乎所有的分區，例如，按照user_id分區，查詢收藏了一個商品的所有用戶需要訪問所有的分區；
●目前廣泛使用的關系數據庫存儲引擎都是針對機械硬盤的特點設計的，不能夠完全發揮新硬件（SSD）的能力。

　　另外一種做法是參考分布式表格系統的做法，例如Google Bigtable系統，將大表劃分為幾萬、幾十萬甚至幾百萬個子表，子表之間按照主鍵有序，如果某臺服務器發生故障，它上面服務的數據能夠在很短的時間內自動遷移到集群中所有的其他服務器。這種方式解決了可擴展性的問題，少量突發的服務器故障或者增加服務器對使用者基本是透明的，能夠輕松應對促銷或者熱點事件等突發流量增長。另外，由于子表是按照主鍵有序分布的，很好地解決了范圍查詢的問題。

　　萬事有其利必有一弊，分布式表格系統雖然解決了可擴展性問題，但往往無法支持事務，例如Bigtable只支持單行事務，針對同一個user_id下的多條記錄的操作都無法保證原子性。而OceanBase希望能夠支持跨行跨表事務，這樣使用起來會比較方便。
最直接的做法是在Bigtable開源實現（如HBase或者Hypertable）的基礎上引入兩階段提交（Two-phase Commit）協議支持分布式事務，這種思路在Google的Percolator系統中得到了體現。然而，Percolator系統中事務的平均響應時間達到2～5秒，只能應用在類似網頁建庫這樣的半線上業務中。另外，Bigtable的開源實現也不夠成熟，單臺服務器能夠支持的數據量有限，單個請求的最大響應時間很難得到保證，機器故障等異常處理機制也有很多比較嚴重的問題?？傮w上看，這種做法的工作量和難度超出了項目組的承受能力，因此，我們需要根據業務特點做一些定制。

　　通過分析，我們發現，雖然在線業務的數據量十分龐大，例如幾十億條、上百億條甚至更多記錄，但最近一段時間（例如一天）的修改量往往并不多，通常不超過幾千萬條到幾億條，因此，OceanBase決定采用單臺更新服務器來記錄最近一段時間的修改增量，而以前的數據保持不變，以前的數據稱為基線數據?；€數據以類似分布式文件系統的方式存儲于多臺基線數據服務器中，每次查詢都需要把基線數據和增量數據融合后返回給客戶端。這樣，寫事務都集中在單臺更新服務器上，避免了復雜的分布式事務，高效地實現了跨行跨表事務；另外，更新服務器上的修改增量能夠定期分發到多臺基線數據服務器中，避免成為瓶頸，實現了良好的擴展性。
當然，單臺更新服務器的處理能力總是有一定的限制。因此，更新服務器的硬件配置相對較好，如內存較大、網卡及CPU較好；另外，最近一段時間的更新操作往往總是能夠存放在內存中，在軟件層面也針對這種場景做了大量的優化。

OceanBase系統架構

OceanBase由如下幾個部分組成：
●客戶端：用戶使用OceanBase的方式和MySQL數據庫完全相同，支持JDBC、 C客戶端訪問，等等?；贛ySQL數據庫開發的應用程序、工具能夠直接遷移到OceanBase。
●RootServer：管理集群中的所有服務器，子表（tablet）數據分布以及副本管理。 RootServer一般為一主一備，主備之間數據強同步。
●UpdateServer：存儲OceanBase系統的增量更新數據。UpdateServer一般為一主一備，主備之間可以配置不同的同步模式。部署時，UpdateServer進程和RootServer進程往往共用物理服務器。

●ChunkServer：存儲OceanBase系統的基線數據?；€數據一般存儲兩份或者三份，可配置。
●MergeServer：接收并解析用戶的SQL請求，經過詞法分析、語法分析、查詢優化等一系列操作后轉發給相應的ChunkServer或者UpdateServer。如果請求的數據分布在多臺ChunkServer上，MergeServer還需要對多臺ChunkServer返回的結果進行合并?？蛻舳撕蚆ergeServer之間采用原生的MySQL通信協議，MySQL客戶端可以直接訪問MergeServer。

　　OceanBase支持部署多個機房，每個機房部署一個包含RootServer、MergeServer、ChunkServer以及UpdateServer的完整OceanBase集群，每個集群由各自的RootServer負責數據劃分、負載均衡、集群服務器管理等操作，集群之間數據同步通過主集群的主UpdateServer往備集群同步增量更新操作日志實現。客戶端配置了多個集群的RootServer地址列表，使用者可以設置每個集群的流量分配比例，客戶端根據這個比例將讀寫操作發往不同的集群：

OceanBase客服端

1）請求RootServer獲取集群中MergeServer的地址列表。

2）按照一定的策略選擇某臺MergeServer發送讀寫請求?？蛻舳伺cMergeServer之間的通信協議兼容原生的MySQL協議，因此，只需要調用MySQL JDBC Driver或者MySQL C客戶端這樣的標準庫即可?？蛻舳酥С值牟呗灾饕袃煞N：隨機以及一致性哈希。一致性哈希的主要目的是將相同的SQL請求發送到同一臺MergeServer，方便MergeServer對查詢結果進行緩存。

3）如果請求MergeServer失敗，則從MergeServer列表中重新選擇一臺MergeServer重試；如果請求某臺MergeServer失敗超過一定的次數，將這臺MergeServer加入黑名單并從MergeServer列表中刪除。另外，客戶端會定期請求RootServer更新MergeServer地址列表。

如果OceanBase部署多個集群，客戶端還需要處理多個集群的流量分配問題。使用者可以設置多個集群之間的流量分配比例，客戶端獲取到流量分配比例后，按照這個比例將請求發送到不同的集群。

RootServer

　　RootServer的功能主要包括：集群管理、數據分布以及副本管理。

　　RootServer管理集群中的所有MergeServer、ChunkServer以及UpdateServer。每個集群內部同一時刻只允許一個UpdateServer提供寫服務，這個UpdateServer成為主UpdateServer。這種方式通過犧牲一定的可用性獲取了強一致性。RootServer通過租約（Lease）機制選擇唯一的主UpdateServer，當原先的主UpdateServer發生故障后，RootServer能夠在原先的租約失效后選擇一臺新的UpdateServer作為主UpdateServer。另外，RootServer與MergeServer＆ChunkServer之間保持心跳（heartbeat），從而能夠感知到在線和已經下線的MergeServer＆ChunkServer機器列表。

　　OceanBase內部使用主鍵對表格中的數據進行排序和存儲，主鍵由若干列組成并且具有唯一性。在OceanBase內部，基線數據按照主鍵排序并且劃分為數據量大致相等的數據范圍，稱為子表（tablet）。每個子表的默認大小是256MB（可配置）。OceanBase的數據分布方式與Bigtable一樣采用順序分布，不同的是，OceanBase沒有采用根表（RootTable）+元數據表（MetaTable）兩級索引結構，而是采用根表一級索引結構。

　　如圖所示，主鍵值在[1，100]之間的表格被劃分為四個子表：1～25，26～50，51～80以及81～100。RootServer中的根表記錄了每個子表所在的ChunkServer位置信息，每個子表包含多個副本（一般為三個副本，可配置），分布在多臺ChunkServer中。當其中某臺ChunkServer發生故障時，RootServer能夠檢測到，并且觸發對這臺ChunkServer上的子表增加副本的操作；另外，RootServer也會定期執行負載均衡，選擇某些子表從負載較高的機器遷移到負載較低的機器上。

　　RootServer采用一主一備的結構，主備之間數據強同步，并通過Linux HA（http://www.linux-ha.org）軟件實現高可用性。主備RootServer之間共享VIP，當主RootServer發生故障后，VIP能夠自動漂移到備RootServer所在的機器，備RootServer檢測到以后切換為主RootServer提供服務。

MergeServer

　　MergeServer的功能主要包括：協議解析、SQL解析、請求轉發、結果合并、多表操作等。

　　OceanBase客戶端與MergeServer之間的協議為MySQL協議。MergeServer首先解析MySQL協議，從中提取出用戶發送的SQL語句，接著進行詞法分析和語法分析，生成SQL語句的邏輯查詢計劃和物理查詢計劃，最后根據物理查詢計劃調用OceanBase內部的各種操作符。
　　MergeServer緩存了子表分布信息，根據請求涉及的子表將請求轉發給該子表所在的ChunkServer。如果是寫操作，還會轉發給UpdateServer。某些請求需要跨多個子表，此時MergeServer會將請求拆分后發送給多臺ChunkServer，并合并這些ChunkServer返回的結果。如果請求涉及多個表格，MergeServer需要首先從ChunkServer獲取每個表格的數據，接著再執行多表關聯或者嵌套查詢等操作。

　　MergeServer支持并發請求多臺ChunkServer，即將多個請求發給多臺ChunkServer，再一次性等待所有請求的應答。另外，在SQL執行過程中，如果某個子表所在的ChunkServer出現故障，MergeServer會將請求轉發給該子表的其他副本所在的ChunkServer。這樣，ChunkServer故障是不會影響用戶查詢的。

　　MergeServer本身是沒有狀態的，因此，MergeServer宕機不會對使用者產生影響，客戶端會自動將發生故障的MergeServer屏蔽掉。

ChunkServer

　　ChunkServer的功能包括：存儲多個子表，提供讀取服務，執行定期合并以及數據分發。

　　OceanBase將大表劃分為大小約為256MB的子表，每個子表由一個或者多個SSTable組成（一般為一個），每個SSTable由多個塊（Block，大小為4KB～64KB之間，可配置）組成，數據在SSTable中按照主鍵有序存儲。查找某一行數據時，需要首先定位這一行所屬的子表，接著在相應的SSTable中執行二分查找。SSTable支持兩種緩存模式，塊緩存（Block Cache）以及行緩存（Row Cache）。塊緩存以塊為單位緩存最近讀取的數據，行緩存以行為單位緩存最近讀取的數據。

　　MergeServer將每個子表的讀取請求發送到子表所在的ChunkServer,ChunkServer首先讀取SSTable中包含的基線數據，接著請求UpdateServer獲取相應的增量更新數據，并將基線數據與增量更新融合后得到最終結果。

　　由于每次讀取都需要從UpdateServer中獲取最新的增量更新，為了保證讀取性能，需要限制UpdateServer中增量更新的數據量，最好能夠全部存放在內存中。OceanBase內部會定期觸發合并或者數據分發操作，在這個過程中，ChunkServer將從UpdateServer獲取一段時間之前的更新操作。通常情況下，OceanBase集群會在每天的服務低峰期（凌晨1:00開始，可配置）執行一次合并操作。這個合并操作往往也稱為每日合并。

UpdateServer

　　UpdateServer是集群中唯一能夠接受寫入的模塊，每個集群中只有一個主Update-Server。UpdateServer中的更新操作首先寫入到內存表，當內存表的數據量超過一定值時，可以生成快照文件并轉儲到SSD中?？煺瘴募慕M織方式與ChunkServer中的SSTable類似，因此，這些快照文件也稱為SSTable。另外，由于數據行的某些列被更新，某些列沒被更新，SSTable中存儲的數據行是稀疏的，稱為稀疏型SSTable。

　　為了保證可靠性，主UpdateServer更新內存表之前需要首先寫操作日志，并同步到備UpdateServer。當主UpdateServer發生故障時，RootServer上維護的租約將失效，此時，RootServer將從備UpdateServer列表中選擇一臺最新的備UpdateServer切換為主UpdateServer繼續提供寫服務。UpdateServer宕機重啟后需要首先加載轉儲的快照文件（SSTable文件），接著回放快照點之后的操作日志。

　　由于集群中只有一臺主UpdateServer提供寫服務，因此，OceanBase很容易地實現了跨行跨表事務，而不需要采用傳統的兩階段提交協議。當然，這樣也帶來了一系列的問題。由于整個集群所有的讀寫操作都必須經過UpdateServer,UpdateServer的性能至關重要。OceanBase集群通過定期合并和數據分發這兩種機制將UpdateServer一段時間之前的增量更新源源不斷地分散到ChunkServer，而UpdateServer只需要服務最新一小段時間新增的數據，這些數據往往可以全部存放在內存中。另外，系統實現時也需要對UpdateServer的內存操作、網絡框架、磁盤操作做大量的優化。

OceanBase定期合并＆數據分發

　　定期合并和數據分發都是將UpdateServer中的增量更新分發到ChunkServer中的手段，二者的整體流程比較類似：

1）UpdateServer凍結當前的活躍內存表（Active MemTable），生成凍結內存表，并開啟新的活躍內存表，后續的更新操作都寫入新的活躍內存表。

2）UpdateServer通知RootServer數據版本發生了變化，之后RootServer通過心跳消息通知ChunkServer。

3）每臺ChunkServer啟動定期合并或者數據分發操作，從UpdateServer獲取每個子表對應的增量更新數據。

　　定期合并與數據分發兩者之間的不同點在于，數據分發過程中ChunkServer只是將UpdateServer中凍結內存表中的增量更新數據緩存到本地，而定期合并過程中ChunkServer需要將本地SSTable中的基線數據與凍結內存表的增量更新數據執行一次多路歸并，融合后生成新的基線數據并存放到新的SSTable中。定期合并對系統服務能力影響很大，往往安排在每天服務低峰期執行（例如凌晨1點開始），而數據分發可以不受限制。

總結

以上是生活随笔為你收集整理的OceanBase架构浅析_OceanBase分布式数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。