如何開發一個分布式內存數據庫
目前有很多商用的內存數據庫(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，壓縮數據，盡可能提高性能。