如何開發一個分散式記憶體資料庫(一)

　　目前有很多商用的記憶體資料庫(timesten, atibase)，很多開源的分散式物理資料庫，而成熟的分散式記憶體資料庫卻很少。當然mysql cluster算是一個，但其受控於oracle，真正要拿來商用，費用應該不低。我們從使用記憶體資料庫已有近15年曆史，隨著系統分散式的推進，記憶體資料庫的分散式隨之也提上日程。基於目前的技術儲備，我們相信我們有能力構建一個符合業務要求的(實時計費系統)、可靠的、商用級別分散式記憶體資料庫——暫且叫她 mdbcluster。

一、目標構想：

　　mdbcluster應該具備如下功能：

　　1. 具備一個記憶體資料庫的基本能力。

　　2. 資料節點容器化

　　3. 支援資料分片

　　4. 節點支援水平擴縮容(業務中斷)

　　5. 故障節點快速恢復

　　6. 資料庫操作介面

　　7. 資料3份拷貝，並且支援分散式資料一致性

　　8. 節點支援線上擴容

　　9. 資料庫叢集管理

　　10. 資料庫叢集監控及報表

二、如何實現

　　1. 找一個開源的單機版記憶體資料庫

　　我們並不是要從零開始進行開發，重複造車輪並沒有什麼意義。因此找一個可以駕馭的、簡單的、效能不錯的單機版記憶體資料庫成為不二之選。我承認這裡有很大的風險，如果這一步走錯，可能會導致整個專案的失敗。FastDB進入我們的視線。

　　先說優點：

　　　　a) FastDB是C++寫的，相信效能應該很快，初步實驗支援20W/S update操作。

　　　　b) 支援完整事務及資料庫的基本操作，對我們後面進行能力擴充套件有很大益處。

　　　　c) 故障快速恢復的能力，由於打算執行在容器環境上，這點至關重要。

　　缺點：

　　　　a) 更新的時候需要鎖庫，你沒聽錯，不是行鎖，也不是表鎖，而是庫鎖。索性他支援讀、寫分離，並且效能夠好。考慮到將來節點可水平擴容，單節點處理能力有上限也沒有太大關係。

　　　　b) 支援操作api特殊。並不是通用的SQL，NoSQL，NDBAPI等等。所幸我們在這方面有較豐富的經驗，設計一套adapter並不是太難。

　　　　c) 暫時還沒有想到……

　　2. 設計總體架構

　　a) MDBProxy負責與客戶端通訊，轉發請求訊息，處理分片路由。

　　b) MDBAgent負責資料寫入，由於涉及資料多分片的資料一致性，需要在這個節點處理資料的二階段提交。

　　c) MDBRNode負責資料的讀取操作，可以多程序提高速度。

　　d) MDBWNode負責資料的寫入操作，可以一表一程序，提升效能。

　　e) 暫未畫出分散式的其它節點，待後續更新。

　　3. 介面設計

　　在想出總體架構後，面臨的第一個問題就是資料庫介面的設計。資料庫通常都有個一連線管理，負責管理所有接入資料庫的客戶端，並且要支援連線池。考慮到這塊的複雜性，我們決定資料庫的介面採用http2協議。這樣做有幾個好處：

　　a) 我們有現成的http2的客戶端、服務端實現方案，減少二次開發。

　　b) 未來趨勢，通用性強，後面資料庫除了有C++介面，可能還會有JAVA等語言介面。

　　c) 經過幾年使用，我們發現http2的功能強大，比如tls，server push等功能未來可能用得到。

　　初步想法：在客戶端傳送請求時，在URL中應該帶上分片的hash值，帶上操作的型別（I、U、D、S）。這樣MDBProxy就可以藉此轉發資料，而不用解包。並且包採用JSON格式，因為客戶端的資料通常都比較小。JSON格式有利於快速查詢。

　　在服務端回查詢包的時候，如果測試效能不差，也考慮用JSON，便於擴充套件。否則，考慮採用Protocol Buffer，壓縮資料，儘可能提高效能。