分区

节点变更

路由

特性(高可拓展 高可靠性 高性能)

Nuclear存储系统，是中国最大的SNS网站人人网下属UGC团队在遇到海量的UGC数据存储需求情况下，开发的在高性能、高可靠、可扩展方面有着优良表现的海量数据存储系统。

它参考了dynamo设计文档，并且分析了现存开源no-sql系统的优劣，完整分析了Cassandra、Voldemort代码的基础之上，在UGC小组的努力下，加入了自动平衡机器负载，简单切换底层引擎等特色而适用的功能，还有相关的附属功能，可以使一个系统从普通的DB轻易将数据移到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增加节点时需要制定目标节点的名称，即增加的节点是用来分担目标节点的负载的。这点不同于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数及底层存储引擎的选择。