DHT里面Hash算法的设计，及其如何抵御极端情况下的DoS攻击？

DHT里，要存储的数据对象，根据其id（或者其内容本身），经过hash运算，映射到一个32位或者64位整数的区间范围。譬如可以使用密码学hash，如MD5、SHA1、乃至SHA256。Cassandra 3.0里使用的是Murmur3（非密码学hash）

这里的问题是，既然是hash，就必然存在一种可能性：数据映射的目标区间的分布不均匀。——极端情况下，可能导致大部分数据都被映射到了同一个区间。这成为一个DoS攻击。

怎么解决这个问题呢？引入虚节点（vnode），vnode可以更细地划分hash目标区间，甚至可以是不均匀的。而实际的物理存储节点可以声明自己对于多个vnode的拥有权。

DHT设计的要点是简化了新节点（物理存储）加入或者退出时的数据的re-balance处理。IO需要局部复制的影响范围是最小的。但是DHT仍然没有处理好复制问题。在Cassandra里面，根据默认的3个副本的冗余存储原则，额外的2个副本所在的vnode直接就对应主vnode的后续2个vnodes。

注意，Cassandra虽然说是一个列簇NoSQL系统，实际上就是分布式Key-Value存储系统。每个Column Family可以理解为Primary Key对应的一个Value对象而已。其他很多系统，如Ceph、HBase等等，都是类似的。不过Ceph为解决数据存储的balance分布采用了一个所谓的动态CRUSH算法。意思是其输入隐时地依赖于全局的某些环境参数。

当然，DHT要解决hash的均匀分布，甚至抗DoS，可以考虑其他的方法：譬如多重hash（这让人会联想到Bloom Filter），譬如Re-hash，或者我们也可以考虑强制要求一个客户端源头的伪随机id（或者使用userid）绑定？