一致性哈希的实际应用

前言

今天重看了一下一致性哈希的论文，心里有几处不清楚的地方，求指导

场景

四台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台服务器来完成

回复内容：

前言

今天重看了一下一致性哈希的论文，心里有几处不清楚的地方，求指导

场景

四台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台服务器来完成

根据楼主想要使用一致性哈希算法来看，基本上是把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接口，需要操作时访问该接口即可