nuclear，是中國最大的sns網站人人網下屬ugc團隊在遇到海量的ugc需求情況下，開發的在高性能、高可靠、可擴展方面有著優良表現的海量數據存儲系統。
它參考了dynamo設計文檔，並且分析了現存開源no-sql系統的優劣，完整分析了cassandra、voldemort代碼的基礎之上，在ugc小組的努力下，加入了自動平衡機器負載，簡單切換底層引擎等特色而適用的功能，還有相關的附屬功能，可以使一個系統從普通的db輕易將數據移到nuclear集群中來。
基本介紹
- 中文名：nuclear
- 外文名：nuclear
- 所屬機構：人人網下屬ugc團隊
- 參考：dynamo設計文檔，開源no-sql系統
分區,節點變更,路由,特性,高可拓展,高可靠性,高性能,
分區
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增加節點時需要制定目標節點的名稱，即增加的節點是用來分擔目標節點的負載的。這點不同於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提供伺服器端路由策略，client的請求隨機落在node節點上，由接收到請求的節點處理後續的邏輯。相對於client端路由來說，優點是client無需知道nuclear集群元數據，易於維護；缺點是會造成一定程度的延時，不過我們的測試結果顯示延時在可接受範圍之內。
兩個設計上的tips貢獻給大家:
1. 萬事皆異步
我們在編碼的過程中走了一些彎路，同步的操作在高並發的情況下帶來的性能下降是非常恐怖的，於是乎，nuclear系統中任何的高並發操作都消除了block。no waiting, no delay。
2. 根據系統負載控制執行緒的資源占用
nuclear系統中有不少的執行緒默默無聞的做著各種辛苦的工作，但是它們同樣會占用，我們的解決方案是根據系統負載動態調整執行緒的運行和停止，並達到平衡。
特性
高可拓展
一個nuclear支持1到n(n<2的64平方)個節點(node)的規模，每台伺服器(server)支持部署多個節點。當集群資源達到瓶頸時，可以通過增加新的節點來擴展。增加新節點的過程，系統服務無需停止，無需人工干預遷移數據。nuclear理論上可以無限scale-out。
高可靠性
單個節點的crash永遠對系統的運行造成影響，不存在單點風險。數據的寫入參考dynamo的w r>n理論，簡釋之，例如設定系統每一份數據都存儲在3個節點上(n=3)，那么讀的話必須成功讀到兩個節點上的數據才認為讀成功 (r=2)，寫的話必須成功寫到兩個節點上才認為寫成功( w=2)。系統永遠可寫入(hinted handoff)。
高性能
在xeon e5405 cpu的伺服器上，單節點每秒最高2.5w req/s。整個集群的性能取決於一致性級別、n、w、r數及底層的選擇。
