-
nuclear
（一種網絡數據存儲系統）
鎖定
它參考了dynamo設計文檔，並且分析了現存開源no-sql系統的優劣，完整分析了Cassandra、Voldemort代碼的基礎之上，在UGC小組的努力下，加入了自動平衡機器負載，簡單切換底層引擎等特色而適用的功能，還有相關的附屬功能，可以使一個系統從普通的DB輕易將數據移到nuclear集羣中來。
- 中文名
- Nuclear存儲系統
- 外文名
- Nuclear
- 所屬機構
- 人人網下屬UGC團隊
- 參 考
- dynamo設計文檔，開源no-sql系統
nuclear分區
Nuclear是一個分佈式的Key-Value存儲系統，那麼key對應的數據分佈在什麼節點上，需要遵守一定的規則。熟悉MemecachedClient的同學一定清楚一致性Hash的應用，沒錯，HashRing就是我們的不二選擇。在Nuclear中，數據分佈在0~2的HashRing上，Nuclear集羣初始化的時候，根據節點數均分整個Hash Ring。
在N=3時，A,B,C三個節點的配置就是系統需要的最少節點了。Nuclear中，順時針的開始值和結束值確定一個分區管理的數據範圍，同時規定分區的範圍左開右閉。因此，如上圖，我們記錄A,B,C分別管理的分區範圍是：
A {[c,a],[b, c],[a,b]}
B {[a,b],[c,a],[b,c]}
C {[b,c],[a,b],[c,a]}
可以看出，A處理管理自己的分區數據外，還會把自己管理的數據順時針往前複製到2(N-1)個節點中。
nuclear節點變更
Nuclear增加節點時需要制定目標節點的名稱，即增加的節點是用來分擔目標節點的負載的。這點不同於Dynamo的分區策略，節點增加的時候會均衡的從現有的節點竊取分區，Nuclear中增加的節點只會影響到鄰近的三個節點。
記錄N,A,B,C管理的分區如下：
N {[c,n],[b,c],[a,b]}
A {[n,a],[c,n],[b,c]}
B {[a,b],[n,a],[c,n]}
C {[b,c],[a,b],[n,a]}
Nuclear的分區管理模塊將自動的計算出需要同步到N上的數據:
A [a,b] => N
B [b,c] => N
C [c,n] => N
不難明白，其實就是把A,B,C不再需要的數據挪給新的節點了。刪、替換節點原理大同小異，不再冗述。
nuclear路由
Nuclear提供服務器端路由策略，Client的請求隨機落在Node節點上，由接收到請求的節點處理後續的邏輯。相對於Client端路由來説，優點是Client無需知道Nuclear集羣元數據，易於維護；缺點是會造成一定程度的延時，不過我們的測試結果顯示延時在可接受範圍之內。
兩個設計上的Tips貢獻給大家:
1. 萬事皆異步
我們在編碼的過程中走了一些彎路，同步的操作在高併發的情況下帶來的性能下降是非常恐怖的，於是乎，Nuclear系統中任何的高併發操作都消除了Block。no waiting, no delay。
2. 根據系統負載控制後台線程的資源佔用
nuclear特性
nuclear高可拓展
一個Nuclear集羣支持1到n(n<2的64平方)個節點(Node)的規模，每台服務器(Server)支持部署多個節點。當集羣資源達到瓶頸時，可以通過增加新的節點來擴展。增加新節點的過程，系統服務無需停止，無需人工干預遷移數據。Nuclear理論上可以無限Scale-Out。
nuclear高可靠性
單個節點的crash永遠對系統的運行造成影響，不存在單點風險。數據的寫入參考Dynamo的W+R>N理論，簡釋之，例如設置系統每一份數據都存儲在3個節點上(N=3)，那麼讀的話必須成功讀到兩個節點上的數據才認為讀成功 (R=2)，寫的話必須成功寫到兩個節點上才認為寫成功( W=2)。系統永遠可寫入(Hinted HandOff)。
nuclear高性能
在Xeon E5405 CPU的服務器上，單節點每秒最高2.5w req/s。整個集羣的性能取決於一致性級別、N、W、R數及底層存儲引擎的選擇。
