如何開發乙個分布式記憶體資料庫(一)
目前有很多商用的記憶體資料庫(timesten, atibase)，很多開源的分布式物理資料庫，而成熟的分布式記憶體資料庫卻很少。當然mysql cluster算是乙個，但其受控於oracle，真正要拿來商用，費用應該不低。我們從使用記憶體資料庫已有近15年歷史，隨著系統分布式的推進，記憶體資料庫的分布式隨之也提上日程。基於目前的技術儲備，我們相信我們有能力構建乙個符合業務要求的(實時計費系統)、可靠的、商用級別分布式記憶體資料庫——暫且叫她 mdbcluster。
mdbcluster應該具備如下功能：
1. 具備乙個記憶體資料庫的基本能力。
2. 資料節點容器化
3. 支援資料分片
4. 節點支援水平擴縮容(業務中斷)
5. 故障節點快速恢復
6. 資料庫操作介面
7. 資料3份拷貝，並且支援分布式資料一致性
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++介面，可能還會有j**a等語言介面。
c) 經過幾年使用，我們發現http2的功能強大，比如tls，server push等功能未來可能用得到。
初步想法：在客戶端傳送請求時，在url中應該帶上分片的hash值，帶上操作的型別（i、u、d、s）。這樣mdbproxy就可以藉此**資料，而不用解包。並且包採用json格式，因為客戶端的資料通常都比較小。json格式有利於快速查詢。
在服務端回查詢包的時候，如果測試效能不差，也考慮用json，便於擴充套件。否則，考慮採用protocol buffer，壓縮資料，盡可能提高效能。
分布式資料庫的開發 記憶體資料庫
現在的計算機技術的發展，基本上一年一變，特別是網際網路。最近的分布式架構尤其突出，從反向 負載均衡到soa rpc這些東東，基本上都是解決了網路上的瓶頸，其實這網路上的問題大不了就是增加伺服器，多個工具或乙個環節來緩衝訪問的時間和速度。還有最近的springcloud之類的，像這些也就是解決了程式上...
Beanstalkd乙個高效能分布式記憶體佇列系統
高效能離不開非同步，非同步離不開佇列，內部是producer consumer模型的原理。設計中的核心概念 job 乙個需要非同步處理的任務，是beanstalkd中得基本單元，需要放在乙個tube中 tube 乙個有名的任務佇列，用來儲存統一型別的job，是producer和consumer操作的...
如何設計乙個微型分布式架構？
序言 初衷 快取伺服器儲存模型架構 背景 隨著業務頻寬自然增長，使用者端頻寬增長，假設業務回源率不變的情況下，磁碟快取淘汰更新 淘汰 速率變快，表現為以下業務瓶頸 iowait變高 回源頻寬變高，由於磁碟空間大小受限的快取淘汰導致回源率變高 為了說明這個原理。我們假設兩個極端 乙個是裝置磁碟容量無限...