在微服务领域,使用Redis作缓存可并非一件容易的事情。html
像新浪、推特这样的应用,许许多多的热点数据全都存放在Redis这一层,打到DB层的请求并很少,能够说很是依赖缓存了。若是缓存挂掉,流量所有穿透到DB层,其必然不堪其重,整个系统也会随之瘫痪,后果很是严重。 因为缓存数据量很大,Redis快正是快在其基于内存的快速存取,而计算机的内存资源又是十分有限的,故分布式缓存集群面临着伸缩性的要求。java
Redis集群中的各实例之间是并不知道对方的,须要在客户端实现路由法来将key路由到不一样的redis节点。node
该路由算法是关键,它必须让新上线的缓存服务器对整个分布式缓存集群影响最小,使得扩容后,整个缓存服务器集群中已经缓存的数据尽量还被访问到。redis
如果使用通常的对key进行一次hash的算法,则会致使扩容后命中率极低。 以下表所示,当集群由3个节点扩容到4个节点时,会有75%的key没法命中。算法
hash(key) | hash(key)/3 | hash(key)/4 | 是否命中 |
---|---|---|---|
1 | 1 | 1 | 是 |
2 | 2 | 2 | 是 |
3 | 0 | 3 | 否 |
4 | 1 | 0 | 否 |
5 | 2 | 1 | 否 |
6 | 0 | 2 | 否 |
7 | 1 | 3 | 否 |
8 | 2 | 0 | 否 |
9 | 0 | 1 | 否 |
10 | 1 | 2 | 否 |
11 | 2 | 3 | 否 |
12 | 0 | 0 | 是 |
这可太糟糕了,当服务器数量为100台时,再增长一台新服务器,不能命中率将达到99%,这和整个缓存服务挂了一个效果。缓存
而一致性Hash正是为了解决这个问题而出现的,该路由算法经过引入一个一致性Hash环,以及进一步增长虚拟节点层,来实现尽量高的命中率。 使用该算法,当节点由n扩容为n+1时,命中率可保持在n/(n+1)左右。bash
关于该算法的具体原理与网上已经有一些说得很透彻的文章,本文再也不赘述。 下面主要从代码实现及运行的方式来对此算法的效果进行展现。服务器
要对一致性Hash进行验证,要作好准备工做,首先要有一个Redis集群。 这里我经过使用在本机上部署多个Redis实例指向不一样端口来模拟这一形态。数据结构
创建项目目录:$ mkdir redis-conf
将redis的配置copy一份过来并复制为5份,分别命名为redis-6379.conf~redis-6383.conf。负载均衡
须要对其内容进行一些修改才能正常启动,分别找到配置文件中的以下两行并对数字进行相应修改。
port 6379
pidfile /var/run/redis_6379.pid
复制代码
而后就能够分别启动了:redis-server ./redis-6379 &
能够使用redis-cli -p 6379
来指定链接的redis-server。 不妨进行一次尝试,好比在6379设置key 1 2,而到6380 get 1只能获得nil,说明它们是各自工做的,已经知足能够测试的条件。
思路是这样的: 部署4个节点,从6379到6382,经过一致性Hash算法,将key: 0~99999共100000个key分别set到这4个服务器上,而后再部署一个节点6383,这时再从0到99999开始get一遍,统计get到的次数来验证命中率是否为指望的80%左右(4/5)。
一致性Hash算法的实现严重借鉴了这篇文章,使用红黑树来作数据结构,来实现log(n)的查找时间复杂度,使用FNV1_32_HASH哈希算法来尽量使key与节点分布得更加均匀,引入了虚拟节点,来作负载均衡。
建议读者详细看下这篇文章,里面的讲解很是详细易懂。
下面是我改写事后的代码:
package org.guerbai.io.jedistry;
import redis.clients.jedis.Jedis;
import java.util.*;
class JedisProxy {
private static String[][] redisNodeList = {
{"localhost", "6379"},
{"localhost", "6380"},
{"localhost", "6381"},
{"localhost", "6382"},
};
private static Map<String, Jedis> serverConnectMap = new HashMap<>();
private static SortedMap<Integer, String> virtualNodes = new TreeMap<>();
private static final int VIRTUAL_NODES = 100;
static
{
for (String[] str: redisNodeList)
{
addServer(str[0], str[1]);
}
System.out.println();
}
private static int getHash(String str) {
final int p = 16777619;
int hash = (int)2166136261L;
for (int i = 0; i < str.length(); i++)
hash = (hash ^ str.charAt(i)) * p;
hash += hash << 13;
hash ^= hash >> 7;
hash += hash << 3;
hash ^= hash >> 17;
hash += hash << 5;
// 若是算出来的值为负数则取其绝对值
if (hash < 0)
hash = Math.abs(hash);
return hash;
}
private static String getServer(String node) {
// 获得带路由的结点的Hash值
int hash = getHash(node);
// 获得大于该Hash值的全部Map
SortedMap<Integer, String> subMap =
virtualNodes.tailMap(hash);
// 第一个Key就是顺时针过去离node最近的那个结点
if (subMap.isEmpty()) {
subMap = virtualNodes.tailMap(0);
}
Integer i = subMap.firstKey();
// 返回对应的虚拟节点名称,这里字符串稍微截取一下
String virtualNode = subMap.get(i);
return virtualNode.substring(0, virtualNode.indexOf("&&"));
}
public static void addServer(String ip, String port) {
for (int i = 0; i < VIRTUAL_NODES; i++)
{
String virtualNodeName = ip + ":" + port + "&&VN" + String.valueOf(i);
int hash = getHash(virtualNodeName);
System.out.println("虚拟节点[" + virtualNodeName + "]被添加, hash值为" + hash);
virtualNodes.put(hash, virtualNodeName);
}
serverConnectMap.put(ip+":"+port, new Jedis(ip, Integer.parseInt(port)));
}
public String get(String key) {
String server = getServer(key);
Jedis serverConnector = serverConnectMap.get(server);
if (serverConnector.get(key) == null) {
System.out.println(key + "not in host: " + server);
}
return serverConnector.get(key);
}
public void set(String key, String value) {
String server = getServer(key);
Jedis serverConnector = serverConnectMap.get(server);
serverConnector.set(key, value);
System.out.println("set " + key + " into host: " + server);
}
public void flushdb() {
for (String str: serverConnectMap.keySet()) {
System.out.println("清空host: " + str);
serverConnectMap.get(str).flushDB();
}
}
public float targetPercent(List<String> keyList) {
int mingzhong = 0;
for (String key: keyList) {
String server = getServer(key);
Jedis serverConnector = serverConnectMap.get(server);
if (serverConnector.get(key) != null) {
mingzhong++;
}
}
return (float) mingzhong / keyList.size();
}
}
public class ConsistencyHashDemo {
public static void main(String[] args) {
JedisProxy jedis = new JedisProxy();
jedis.flushdb();
List<String> keyList = new ArrayList<>();
for (int i=0; i<100000; i++) {
keyList.add(Integer.toString(i));
jedis.set(Integer.toString(i), "value");
}
System.out.println("target percent before add a server node: " + jedis.targetPercent(keyList));
JedisProxy.addServer("localhost", "6383");
System.out.println("target percent after add a server node: " + jedis.targetPercent(keyList));
}
}
复制代码
以上代码对参考文章进行了一些改进。
首先,参考文章的getServer方法会有些问题,当key大于最大的虚拟节点hash值时tailMap方法会返回空,找不到节点会报错,其实这时应该去找hash值最小的一个虚拟节点。我加了处理,把这个环连上了。
下面getHash方法为FNV1_32_HASH算法,能够不用太在乎。
VIRTUAL_NODES的值比较重要,当节点数目较少时,虚拟节点数目越大,命中率越高。
在程序设计上也有很大的不一样,我写了JedisProxy类,来作为client访问Redis的中间层,在该类的static块中利用服务器节点生成虚拟节点构造好红黑树,getServer里根据tailMap方法取出实际节点的地址,再由实际节点的地址直接拿到jedis对象,提供简单的get与set方法,先根据key拿特定的jedis对象,再进行get, set操做。
addServer静态方法给了其动态扩容的能力,能够看到在main方法中,经过调用JedisProxy.addServer("localhost", "6383")
便直接增长了节点,不须要停应用。 targetPercent方法是用来统计命中率用。
当虚拟节点为5时,命中率约为60%左右,把它加大到100后,能够到达预期的80%的命中率。
好的,完美。