【摘要】?本文提出了一種通過引入內存數據庫層，建立兩層多分區分布式數據庫架構。此方案用于解決海量高并發系統的數據存儲和訪問問題，尤其適用于電子商務等數據模型復雜且業務復雜的互聯網站。

?

這些年互聯網站發展迅猛，為應對海量數據下的高并發訪問，產生了各種分布式架構設計思想，例如Key-Value引擎，數據分區等。而對于電子商務類網站，海量數據問題還有一個重要特點，就是數據結構化及數據之間的關聯，淘寶如此，阿里巴巴也是如此，這是與社區、視頻、?博客等互聯網站的顯著差異。

?

1.? NoSQL?是靈丹妙藥嗎？

NoSQL、Key-Value?引擎如BigTable、Cassendra等在很多大型網站被采用，很好的解決了海量數據存儲和訪問問題。而對于電子商務類網站，Key-Value和NoSQL并不是解決此問題的靈丹妙藥。最多它們僅能用于一些數據模型較為簡單的應用。

原因有兩個方面：

1）數據模型復雜

淘寶和阿里巴巴的會員、寶貝、供求、訂單等核心實體數據模型復雜，屬性個數幾十到上百個。例如：會員(Member)就包含基本信息、聯系、工商、賬戶等多個域的信息；另外，核心實體之間，外圍實體與核心實體之間還存在復雜的關聯。

2）業務復雜：

模型的復雜源于業務和邏輯的復雜。電子商務網站大量查詢場景是結構化查詢，例如：

在淘寶上查詢“賣家在江浙滬，價格在50-200元的男士T恤”，

在阿里巴巴上“列出某個會員所有待發貨的訂單”

這類查詢（當然，阿里巴）主要針對多個非主鍵字段,?即便對于BigTable、Cassandra?這樣的基于Column的Key-Value數據庫，其簡單的Query API還無法勝任此類需求。 因此在阿里巴巴和淘寶，Oracle、MySQL?等關系數據庫將仍然扮演重要角色。

?

2. MySQL?集群

引入K-V引擎等非關系數據庫無非是要解決海量數據在高并發環境下的高效讀寫問題，最大程度在可靠的持久化(Durable)與高訪問性能?(Performance)?之間選擇一個平衡點。在高度結構化系統中，同樣的考慮驅使我們需要考慮另外的解決方案。

目前一種通行的做法是?MySQL?讀寫分離式集群，1個或少數Master寫，多數Slave讀，Master與Slave進行變更數據的同步。首先，這種方案經過大量的實踐，可靠且可行。

然而，直接向DB執行寫操作，仍然比較耗時(參見表1，表2)，數據復制，也可能存在不一致延時的情形。是否還有更快的方案？

3.?內存型關系數據庫

可靠的持久化指數據存儲到磁盤等設備上。圖1展示了傳統磁盤數據庫的基本訪問模式。

?

?圖1

拋開持久化的可靠性，即數據可以先不存儲到磁盤上(Disk)，內存存儲的性能遠高于磁盤存儲。下表展示了針對Oracle和Altibase所做的性能對比，后者在插入和查詢上性能是Oracle的5-7倍。

?

數據庫	測試結果	TPS
Oracle	203秒	246條/秒
Altibase	28.32秒	1785條/秒

表1. Oracle、Altibase性能對比?-插入5萬條?^【7】

?

數據庫	測試結果	TPS
Oracle	885秒	112條/秒
Altibase	170秒	588條/秒

表2 Oracle、Altibase性能對比?–?關聯查詢10萬條^【7】

?

由此可見：Pm? >>>? Pd?

（Pm -?內存數據庫讀寫性能，?Pd -?磁盤數據庫讀寫性能）

?

結合前面分析的模型復雜性和業務復雜性原因，關系數據庫（RDBMS）必須采用。因此，這兩點考慮可以推導出另一個解決思路：內存型關系數據庫。

?

?	磁盤型關系數據庫	Key-Value引擎	內存型關系數據庫
功能?-結構化操作和查詢等	Y	N	Y
性能	低	高	高

表3. DB選型對比分析

?

這個方案里，我們可以將內存先看做一種“磁盤”，讀寫操作都針對內存數據庫進行，不再直接與磁盤數據庫交互，這較好的避免了單純MySQL?讀寫分離架構存在的時間延遲和一致性問題。如下圖所示：

?

?圖2

4.?內存數據庫的持久化

數據最終還是要存儲到磁盤(Disk)上，內存數據庫中的數據變化需要復制到與磁盤數據庫上。這時，從內存向磁盤復制數據的過程可以看作原始寫操作的異步操作，顯然，異步操作使得前端的寫操作顯得更快。如下圖所示：

?

?圖3

在事務型(OLTP)系統中，內存數據庫中在啟動時需要和磁盤數據庫保持一致。 因此，內存數據庫需要有相同的庫表定義；并且在第一啟動時，將所需庫表數據加載到內存數據庫中。

?

5.?內存數據庫集群化

目前，經典的MySQL集群，通過讀寫分離，水平切分，實現海量數據存儲。為應對海量數據存儲，內存數據庫同樣需要做集群。垂直和水平切分策略，可用性策略與MySQL集群架構設計基本相同。如下圖所示，其中?Ameoba?是分布式數據庫代理，它進行數據路由等控制。

唯一的不同是，由于內存數據庫的高性能，可以不再進行讀寫分離設計。

?

?圖4

?

6.?混合分區（Hybrid Shard）

接第4節的分析，內存數據最終仍需要持久化到磁盤。這里需要一種混合分區(Hybrid Shard)來解決。即原來一個MySQL節點承擔的一個水平分區，將由一個內存數據庫節點和一個MySQL節點共同組成。

H-Shard = MDB + MySQL.

?

這種數據庫架構將形成由兩級數據庫(2LDB)，混合分區構成的集群。的如下圖所示：

?

?圖5

?

7.?內存數據庫選型

常見的內存數據庫產品包括商業版和免費版兩類。商業版如：Altibase，Timesten，Berkley DB等。他們在電信，金融，證券等高性能計算應用中運用較為廣泛。商業版功能強大，然而，價格比較昂貴，不適合目前“廉價PC+免費軟件”的架構搭建思想。

筆者曾就職與中國移動系統提供商，其中計費、運營等系統就運用Timesten提供高性能運算，但還主要用于高頻度小數據計算，如計費批價，優惠計算，信控等，采用單節點模式使用。

開源領域產品主要有H2，HsqlDB，Derby等。在混合分區架構中，內存數據庫將承擔OLTP的職責，因此除了讀寫性能外，功能的完備，事務等都需要作為優先評估的因素。

?

8.?新架構的挑戰

通過引入內存數據庫作為中間持久層，再加入分布式架構以支撐海量數據訪問，這種架構設計頗具挑戰。最先而易見的情況就是新架構的復雜度，正如大規模MySQL集群架構誕生初始一樣。

我們以?H2?，一個開源的高性能內存數據庫為例說明：

1)??整合?Ameoba?與?H2

Ameoba?是分布式數據庫代理，它與?MySQL?整合已經在阿里巴巴核心業務中成功運用。如果僅將數據庫節點看作一個存儲，MySQL Node?和?H2 Node?并無本質區別。JDBC驅動，DB切分，路由，皆由Ameoba?統一負責。

?

2)??異步持久化

每個邏輯混合分區= H2 + MySQL，誰來完成H2?中的數據變更異步寫入?MySQL？

比較好的方案是內存數據庫提供實時增量的復制器（Replicator)?，例如：基于聯機日志復制的雙機熱備機制。AltiBase?等產品就提供了此功能。

?

3）高可用性

內存數據庫一旦崩潰，數據不復存在。因此首先要做到數據快速異步寫入MySQL作持久化存儲。同時要有健壯的容錯和Failover機制，保證一個H2節點崩潰，同一邏輯分區中的替補H2節點立即頂替工作。

一種方案是分布式數據庫代理如?Ameoba?來解決，例如：每個Shard，H2至少設2個節點，采用Primary-Secondary模式，如圖6所示：

?

?圖6

?

另一種方案是前面提到的內存數據庫實時復制功能。

雖然有些內存DB如H2自身能支持內存，磁盤兩級存儲，但其自身提供的磁盤存儲和訪問方案可靠性不如?MySQL。因此，使用內存式Primary-Secondary?模式更為可行。

?

4）分布式事務

數據庫切分架構帶來分布式事務問題，對一些事務要求較高的場景，這頗具挑戰。Ameoba?目前還在解決中。Ameoba + H2組合面臨同樣的挑戰。

目前一種比較一致意見和做法就是冷處理——盡量不用事務。 一致性問題根據業務的特點，采用數據訂正來解決；個別業務使用補償事務。因為目前大部分應用，即便是核心業務，對事務的要求也不高。

?

9.?進一步思考

1） 多種數據切分模式

????在一個大型互聯網站，不同的應用和數據需要做不同的處理。在總體垂直切分模式基礎上，選擇數據量大的功能進行水平切分，例如：供求、訂單、交易記錄。

???

2）數據緩存（Data Cache）

雖然內存數據庫層(MDB)能更高效支撐交易型數據庫，特別是應對結構化應用及復雜查詢服務，但對高頻度的查詢(Query)和實體查找(Find)，Key-Value緩存仍然是一項必要的設計。Cache能提供更高的查詢速度，并減少對MDB的訪問壓力，特別是讀寫密集的高并發場景。因為這個架構中，內存數據庫仍然作為一種存儲Store，而不是Cache。

?

?圖7

上圖展示了，MDB層之上還需要DCL層來提供高性能緩存服務。

?

10.?總結

本文提出了一種通過引入內存數據庫層，并建立兩層，多分區的分布式數據庫架構。此方案用于解決海量高并發系統的高性能數據存儲和訪問問題，尤其是電子商務類等業務復雜的互聯網站。其核心思想是：

1）高性能：是通過內存數據庫提供高性能關系數據庫存取服務，這是此架構的最主要目標；

2）持久化：通過兩級數據庫及異步寫完成持久化；

3）海量數據支撐：通過垂直和水平分區實現海量數據的支撐；

4）高可用性：在Ameoba基礎上，通過主備節點進一步實現MDB的高可用性；二級磁盤數據庫可以實現數據的快速恢復。

?

【參考資料】

1.??阿里巴巴?Ameoba分布式數據庫設計和實踐

2.?岳旭強,?《淘寶網架構師岳旭強的年度展望》，?http://www.infoq.com/cn

3.?廣東移動BOSS2.0分布式數據庫架構方案，計費系統設計和實踐.

4. Cassandra，http://cassandra.apache.org/

5. Oracle, Timesten?官方文檔,?http://www.oracle.com/timesten/index.html

6. Fenng,《Oracle?內存數據庫-TimesTen》,?http://www.dbanotes.net/database/oracle_timesten.html

7.?張澄,包文菖,《內存數據庫在BSS賬務處理中的應用》，《計費&OSS世界》，http://database.51cto.com/art/200612/36973.htm

8. Titan,《常用內存數據庫介紹》，http://titan.javaeye.com/blog/364345

9. Ricky Ho,?《NoSQL的模式》，程序員2010-1；《NoSQL?數據庫的查詢處理》，程序員2010-2

https://blog.csdn.net/tolys/article/details/5963506

總結

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

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