前言
关于这个问题，Google了很多答案，基本都是在说相比redis现在采用的哈希槽，一致性哈希更容易造成缓存雪崩，不过村长我总感觉有点儿牵强；
首先：一致性哈希的虚拟节点和哈希槽的作用基本是相同的，这两者都可以达到目的；
其次，哈希槽的方案，理论上也会出现雪崩，下文会讲到；
最后：国内的Codis使用的就是一致性哈希方案，不过codis对底层做了改动。
哈希槽方案的雪崩理论
比如机器的机器A上存有热点key，某一时刻大量访问涌入导致A宕机，这时sentinel通过选取从slave中拉出一台当做master，但这并没有解决根本问题；
hot-key依然存在，slave很可能继续宕机。除非slave的性能比master高的多得多，但这几乎不可能，毕竟大家都是把好货用到master上。
这就产生一个问题，为什么Redis官方没有采用一致性哈希方案？
村长试解答
简单说说村长的一点儿想法吧，欢迎交流：
先构造一个场景，比如，集群有ABC三台机器，机器A没能抵挡住洪荒之力，宕机了。
如果直接使用一致性哈希（非codis那种做过优化的），会导致循环雪崩。
按照一致性哈希算法，会顺时针继续遍历，有可能A的流量会被打到B或C上，极端情况都打到了B，那大概率会导致B宕机；
B宕机之后，集群只剩一台C，那这时候不用想，也会宕机；
如果要恢复数据，则需要同时恢复A、B、C两台机器，因为这三台都挂了；
真可谓一荣俱荣，一损俱损。
如果使用Redis官方的哈希槽方案，至少数据恢复相对来说简单一些。
A宕机之后，由其slave（sentinel 模式从 slave 中选举一个新 master）服务器接管槽位，继续运行；
如果新 master 也宕机，这个槽位的数据就无法获取了，直接返回：CLUSTERDOWN 的 err 信息，这种情况下集群就会下线，需要人工处理；
按村长的理解，其实这种方案更应该称为 人工强行高可用 方案，说白了就是：让问题提前暴露，人工干预；
可见，
哈希槽方案，如果要恢复集群，只需要恢复A节点即可，逻辑简单易懂，恢复成本较小。
网友评论