Hash一致性

背景：为什么要使用redis集群

比如 redis 这样的缓存，单机支持10万次/秒的并发，那超过10万次/秒的并发或者海量的数据存储，需要怎样，才能提高系统效率呢。即怎么解决高并发和海量存储问题。
这时候很明显需要将缓存redis做成集群，第一解决单点故障，第二集群环境可以解决高并发和海量存储问题

问题：集群如何管理，数据放到哪个节点，数据应该从哪个节点读取

方法1：hash求余
比如现在有3个redis节点，根据存入值得key，求其hash值（hash值是非0的正整型），如果是200，200%3=2，那么这个数据就是放在编号为2的节点上，取值也在这个节点取值。
优点：hash散列分布，每个节点的压力都很平均
缺点：增加节点的时候，大概率会让缓存失效，原本N个节点，现在增加1个节点，那么失效概率是 N/N+1

方法2：Hash一致性
从0到int.max，形成一个圆环
然后将节点的某个属性比如节点名称根据hash值，放到圆环对应位置
然后将值得key转换成hash值，放到对应圆环的相应位置，找到该位置顺时针方向下一个节点圆环位置，该值就存到这个节点上，也从这个节点上获取
优点：增加一个节点的时候，失效的概率最大最大为1/N
缺点：节点不平均分配数据，增加一个节点之后，只会减轻该节点顺时针方向的后一个节点的压力，不能帮其他节点减缓压力

方法3：虚拟节点Hash一致性
上述方法2，不足之处的原因节点数量太少了。
hash本来就是散列分布的，但是由于实际原因，实际部署的节点不可能成百上千，所以在此基础上，可以由一个实际节点虚拟化成很多虚拟节点，便可以保证节点的散列分布，从而达到每个节点的负载是均衡的，增加一个节点，对于其他节点的压力帮助也是同等的。
实践证明一个实体节点分裂为150个虚拟节点比较合适。