Redis存储方案选择：hash环和hash链的比较

1、hash链

• 原理简介：
  每个数据存储进来的时候，要根据hash算法，进行算值取余，存入到对应的机器中。取数据的时候，用同样的hash算法对key进行计算，即可取出数据。
  
• 应用场景：
  Redis集群扩容或宕机缩减，那么就需要进行全库数据的重洗，hash取模的值调整。这样，就比较耗费时间。所以，该方案，要预先估计一下自己公司业务的数据量多大，服务器的存储能力多大，然后，考虑在扩容时，所需的时间多久，只要在允许的时间范围内，能够完成重洗数据，那就可以采取该方案。该方案的一个好处就是，简单。存数据简单，取数据简单，理解容易。

2、hash环

• 原理简介
  上面说的Hash链，只经过了1次hash，即把key hash到对应的机器编号。
  而Hash环有2次Hash：
  （1）把所有机器编号hash到这个环上
  （2）把key也hash到这个环上。然后在这个环上进行匹配，看这个key和哪台机器匹配。
  
  这样，每个机器负责对应段上的数据。
• 应用场景
  当hash链性能满足不了公司业务数据量的时候，就要采取该方案进行性能提升。
  当服务器缩减时，对应段数据向下游转移即可，这样，就不会影响到其他段服务器的数据。
  当服务器扩容时，对应服务器下游的服务器数据要进行重洗，把部分数据转移到新扩容的服务器上即可。这样，在查找时，按照最新的hash算法取余，即可取出对应的数据。
  这相较于hash链，进行全库冲洗，还是节省了很多
  也就是说，hash链和hash环，在新增服务器的时候，都是要冲洗数据的，只是，hash链是全库冲洗（算法复杂度是N），hash环是下游节点冲洗（算法复杂度是1）

那么会有道友问，我直接上第二种方案不就得了。
这显然是不行的。
原因：
hash环是有大小的，它的特点是把hash链首尾相连，那么，假设你公司业务只有百万级数据量，你设置成一个hash环。假设，hash环周长是100，小厂有4台服务器，第一次可以人为均匀分布到环上，但是，如果业务量数据增加，导致需要扩容。这时候，如果你对hash环进行扩周长，如果不重新分配服务器在环上的位置，那就会出现数据倾斜问题，如果，重新均匀分布服务器在环上的位置，那么，就要全库重洗数据。所以，这样就和hash链没什么区别。还多出一个数据倾斜问题。

那么有道友就说了，那我把hash环周长设置的超大。这样，不就可以减轻扩容时，数据倾斜问题的严重性了吗？并不是这样，当你保持环周长不变的前提下扩容的时候，数据倾斜和环的周长并没有关系。只是和你扩容的服务器策略有关，就是，假设第一次设置4台服务器，那么，你扩容的服务器必须是2的N次方台，这样才能人为的避免数据倾斜。那么，你小厂有这个实力吗？显然没有，不划算。

另外，你的环周长越大，也就意味着取余的除数越大，那么，计算取余的时间就越久，比如，你对2取余，口算即可。你对2的32次方取余，那就要多用很多时间，这样，随着积累，你浪费的时间就很多了。相对于公司业务，数据量不大，但是，损耗的计算时间却很多，那就很不划算了。所以，环的周长也是要考虑的点。

所以，使用hash环算法，要考虑两点
1、公司自身实力，每次扩容需要的服务器数据量是：a*2^n。其中，a是第一次均匀分布的服务器数据量，n>=0的整数。这个扩容方法，解决数据倾斜问题。
2、hash环周长大小选择。周长越大，计算越耗费时间。所以，要根据公司业务量大小，选择合理的周长大小，不能太小，否则经常扩容，不能太大，浪漫每次的取余时间。
3、数据倾斜问题的本质，就在于服务器节点在环上的分布是否均匀还是密集。分布密集了，那就会出现数据倾斜问题。