一致性哈希原理及应用浅析

背景

现实场景

1. 单个节点的容量达到上限，无法继续单点增加内存，如何解决？
2. 单个节点支撑的QPS达到上限，如何解决？

初步方案

   增加N个缓存节点，为了保证缓存数据的均匀，一般情况会采用对key值hash，然后取模的方式，然后根据结果，确认数据落到哪台节点上：如下：

hash(key)%N

很好，这个的确解决了上面的问题，实现了初步的分布式存储，数据均匀分散到了各个节点上，流量请求也均匀的分散到了各个节点。

方案问题

1. 某台服务器突然宕机。缓存服务器从N变为N-1台。 hash(key)%(N-1)
2. 缓存容量达到上限或者请求处理达到上限，需要增加缓存服务器，假定增加1台，则缓存服务器从N变为N+1。hash(key)%(N+1)

       增加或者删除缓存服务器的时候，意味着大部分的缓存都会失效。这个是比较致命的一点，缓存失效，如果业务为缓存不命中，查询DB的话，会导致一瞬间DB的压力陡增。可能会导致整个服务不可用。

目标

   增删机器时，希望大部分key依旧在原有的缓存服务器上保持不变。举例来说：key1，key2，key3原先再Cache1机器上，现在增加一台缓存服务器，希望key1，key2，key3依旧在Cache1机器上，而不是在Cache2机器上。

原理

基本概念

        一致性hash算法是希望在增删节点的时候，让尽可能多的数据不失效。

   判断hash算法好坏的四个标准：

• 平衡性：平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。
• 单调性：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。
• 分散性：在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。
• 负载：负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同 的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

       使用常见的hash算法可以把一个key值哈希到一个具有2^32个桶的空间中。也可以理解成，将key值哈希到 [0, 2^32] 的一个数字空间中。 我们假设这个是个首尾连接的环形空间。

        

一致性Hash算法

1. 构造hash环空间
2. 把节点（服务器）映射到hash环
3. 把数据对象映射到hash环
4. 把数据对象映射到节点

   把数据用hash函数（如MD5，CRC32），映射到一个很大的空间里，如图所示。数据的存储时，先得到一个hash值，对应到这个环中的每个位置，如k1对应到了图中所示的位置，然后沿顺时针找到一个机器节点B，将k1存储到B这个节点中。

   如果B节点宕机了，则B上的数据就会落到C节点上，也就是说只有C节点受到影响，也就意味着解决了最开始的方案中可能的雪崩问题。如下图所示：

上面的简单的一致性hash的方案在某些情况下但依旧存在问题：一个节点宕机之后，数据需要落到距离他最近的节点上，会导致下个节点的压力突然增大，可能导致雪崩，整个服务挂掉。

1. 之前请求到B上的流量转嫁到了C上，会导致C的流量增加，如果之前B上存在热点数据，则可能导致C扛不住压力挂掉。
2. 之前存储到B上的key值转义到了C，会导致C的内容占用量增加，可能存在瓶颈。

   当上面两个压力发生的时候，可能导致C节点也宕机了。那么压力便会传递到D上，又出现了类似滚雪球的情况，服务压力出现了雪崩，导致整个服务不可用。

虚拟节点

图中的A1、A2、B1、B2、C1、C2、D1、D2都是虚拟节点，机器A负载存储A1、A2的数据，机器B负载存储B1、B2的数据，机器C负载存储C1、C2的数据。由于这些虚拟节点数量很多，均匀分布，因此不会造成雪崩现象。

   虚拟节点的 hash 计算可以采用对应节点的 IP 地址加数字后缀的方式。例如假设 cache A 的 IP 地址为202.168.14.241 。

   引入虚拟节点前，计算 cache A 的 hash 值：

Hash(“202.168.14.241”);

   引入虚拟节点后，计算虚拟节点cache A1 和 cache A2 的 hash 值：

Hash(“202.168.14.241#1”);  // cache A1

Hash(“202.168.14.241#2”);  // cache A2

   每个实际节点的N个虚拟节点尽量随机分布在整数环上, 增加cache节点时,就能尽量保证移动到新cache节点的key来自于不同的cache节点, 从而保证负载均衡. 

hash(key) -> 虚拟节点 -> 真实节点

JAVA实现

public class Shard<S> { // S类封装了机器节点的信息 ，如name、password、ip、port等

    private TreeMap<Long, S> nodes; // 虚拟节点
    private List<S> shards; // 真实机器节点
    private final int NODE_NUM = 100; // 每个机器节点关联的虚拟节点个数

    public Shard(List<S> shards) {
        super();
        this.shards = shards;
        init();
    }

    private void init() { // 初始化一致性hash环
        nodes = new TreeMap<Long, S>();
        for (int i = 0; i != shards.size(); ++i) { // 每个真实机器节点都需要关联虚拟节点
            final S shardInfo = shards.get(i);

            for (int n = 0; n < NODE_NUM; n++)
                // 一个真实机器节点关联NODE_NUM个虚拟节点
                nodes.put(hash("SHARD-" + i + "-NODE-" + n), shardInfo);

        }
    }

    public S getShardInfo(String key) {
        SortedMap<Long, S> tail = nodes.tailMap(hash(key)); // 沿环的顺时针找到一个虚拟节点
        if (tail.size() == 0) {
            return nodes.get(nodes.firstKey());
        }
        return tail.get(tail.firstKey()); // 返回该虚拟节点对应的真实机器节点的信息
    }

    /**
     *  MurMurHash算法，是非加密HASH算法，性能很高，
     *  比传统的CRC32,MD5，SHA-1（这两个算法都是加密HASH算法，复杂度本身就很高，带来的性能上的损害也不可避免）
     *  等HASH算法要快很多，而且据说这个算法的碰撞率很低.
     *  http://murmurhash.googlepages.com/
     */
    private Long hash(String key) {

        ByteBuffer buf = ByteBuffer.wrap(key.getBytes());
        int seed = 0x1234ABCD;

        ByteOrder byteOrder = buf.order();
        buf.order(ByteOrder.LITTLE_ENDIAN);

        long m = 0xc6a4a7935bd1e995L;
        int r = 47;

        long h = seed ^ (buf.remaining() * m);

        long k;
        while (buf.remaining() >= 8) {
            k = buf.getLong();

            k *= m;
            k ^= k >>> r;
            k *= m;

            h ^= k;
            h *= m;
        }

        if (buf.remaining() > 0) {
            ByteBuffer finish = ByteBuffer.allocate(8).order(ByteOrder.LITTLE_ENDIAN);
            finish.put(buf).rewind();
            h ^= finish.getLong();
            h *= m;
        }

        h ^= h >>> r;
        h *= m;
        h ^= h >>> r;

        buf.order(byteOrder);
        return h;
    }

}

应用

1. memcache、redis服务器等缓存服务器的负载均衡（分布式cache）；
2. MySQL的分布式集群（分布式DB）；
3. 大量session的共享存储（分布式文件，或session服务器等）。

   twemproxy 是 twitter 开源的一个轻量级的后端代理，兼容 redis/memcache 协议，可用以管理 redis/memcache 集群。

   twemproxy 内部有实现一致性哈希算法，对于客户端而言，twemproxy 相当于是缓存数据库的入口，它无需知道后端的部署是怎样的。twemproxy 会检测与每个节点的连接是否健康，出现异常的节点会被剔除；待一段时间后，twemproxy 会再次尝试连接被剔除的节点。

   通常，一个 Redis 节点池可以分由多个 twemproxy 管理，少数 twemproxy 负责写，多数负责读。twemproxy 可以实时获取节点池内的所有 Redis 节点的状态，但其对故障修复的支持还有待提高。解决的方法是可以借助 redis sentinel 来实现自动的主从切换，当主机 down 掉后，sentinel 会自动将从机配置为主机。而 twemproxy 可以定时向 redis sentinel 拉取信息，从而替换出现异常的节点。