一致性哈希的实际应用
前言
今天重看了一下一致性哈希的论文，心里有几处不清楚的地方，求指导
场景
四台server服务器（192.168.1.1-4），redis数据库，存储key-value键值对
问题1
首先，redis的key-value数据一般需要3份备份，对应到一致性哈希的场景，可以说有一台主服务器，和2台从服务器。问题：从服务器的选取是一致性哈希代码里选取三个不同的server，还是选取一个server，然后给这个server再配上两台从服务器呢（这样服务器从原先的4台，增加到4 + 2 * 4 = 12台），我考虑用memcache记录key、主、从分布表
问题2
如果冗余到其他两台服务器，假设是A\B\C\D四台服务器，key的主库是A，备份库在BC上，那当A单点故障，BC之间如何选择，BC上针对A节点的增删改数据如何再恢复给A节点吗？我看了NRW模型，但是没能完全理解
解答1
群里有人提示，服务器端可以用HAproxy+Keepalived实现每个机器主备模式，其实相当于一致性哈希的环上真正只有4个可用的target，却需要8台服务器来完成
无辜的宅基腐
10 years, 10 months ago
Answers
根据楼主想要使用一致性哈希算法来看，基本上是把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稳定性会下降；
以上仅为个人一点想法，拿出来和楼主探讨
奈菲爾蒂斯
answered 10 years, 10 months ago