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数及底层存储引擎的选择。