根据楼主想要使用一致性哈希算法来看，基本上是把redis当做缓存使用，而不是数据库；

而使用一致性哈希的主要目的通常都是：当集群中机器数量发生变化时，减少缓存失效范围，防止“雪崩”；

在这种情况下，我想到了另一个问题：是不是一定要用哈希一致性算法？

按照我的想法，根据redis目前提供的一些特性，或许使用下面这种常见架构，就能解决刚才的问题;

1台master，n台slave，然后采取读写分离的方式，master处理写请求，slave负责处理读请求（负载均衡）

这种部署方式有什么优势？

• 当业务访问量猛增时，我们可以快速新增一台redis机器，连上master，当完成主从复制后， 放入到slave集群，开始对外提供服务；

• 当slave集群中有一台机器挂掉后，可以通过某种机制被识别（借鉴sentinel），并将它从slave集群中踢出；

这样子无论slave集群如何变化，都不会出现cache失效或者部分失效问题;

这种部署方式有什么劣势？

• redis目前主从复制过程有个很不好的地方就是：当slave和master在同步过程中，网络出现问题，这时候slave要求master重传而不是续传（重新生成一份RDB文件然后传输）；这样当master中数据很多的时候，影响会很大，所以一个master下挂多个slave稳定性会下降；

以上仅为个人一点想法，拿出来和楼主探讨

这两天看了一点架构的东西，这个问题基本可以关闭了

解决方案

1. 还是采用8个server，主备的方式，采用一致性哈希算法增加节点服务器可以通过虚拟节点和权重来防止数据偏移，这里的节点服务器可以用VIP来标识

2. 主备服务器之间可以采用keepalived方案，对外提供的是虚拟ip，自动故障转移，至于主备服务器的数据库同步，可以用redis提供的主从机制，也可以自己crontab+aof日志，可以再redis数据库上再封装一层insert或者update操作，对外提供api接口，需要操作时访问该接口即可