一致性Hash算法

本文内容主要包括：Hash算法的应用场景，一致性Hash算法原理，以及手写实现一个简单的一致性Hash算法。

Hash算法的应用场景

Hash算法在很多分布式集群产品中都有应用，比如分布式集群架构的Redis，Hadoop，ElasticSearch，MySql分库分表，Nginx负载均衡等等。
主要我们可以将其分为两大类：
1. 请求的负载均衡
例如:Nginx的ip_hash策略，Nginx的ip_hash策略可以在客户端ip地址不变的情况下，将其发出的请求始终路由到一台目标服务器上，实现会话粘滞，避免处理session共享的问题。
2. 分布式存储
例如：memcached或者Redis分布式集群中，如何确定Key存放的服务器？可以通过Hash算法，比如说：hash（Key）%（服务器数量），余数就是Key存储的机器编号。
那么请求转发的是否均衡，Key在集中中的分布是否均匀很大程度上取决于Hash算法，Hash表内部的Hash算法也一直在更新。

常规Hash算法存在的问题

如果我们不考虑服务器集群的伸缩性，常规Hash算法，比如余数Hash几乎可以满足绝大多数的路由需求。
但是，当服务器集群需要进行扩容的时候，或者服务器集群中的某一台机器宕机了，事情就往糟糕的方向发展了。
我们以一个分布式缓存集群为例子，这个分布式缓存的集群，采用余数Hash的策略，将不同的Key值存放在了集群中的不同服务器上，来描述一下扩容和缩容时发生的情况：

1. 先来说一下扩容的情况
   假设我们使用余数Hash算法，集群中3台服务器要扩容到4台服务器，那么计算方式的变化如下：
   m = hash(o) mod n 更新为： m = hash(o) mod （n +1）
   那么大约会有75%被缓存的数据不能正确命中，随着服务器集群规模的增大，这个比例线性上升级，计算公式为N/(N+1)。
   为什么是75%不能命中？以下仅为个人理解：原本3台服务器的集群，我们编号为0,1,2，以编号2的服务器为例，落在编号2服务器上的hash值可以表示为3n+2，而3n+2 mode 4的余数为：1,0,3,2，并且是均匀的，（不确定是否可以通过数学证明）只有余数为2的hash值，才能命中原来的数据缓存，命中率为1/4，也就是75%不能命中。
2. 缩容或者机器宕机的情况
   同理，集群缩容或者宕机，Hash算法需要更新：
   m = hash(o) mod n 更新为： m = hash(o) mod （n -1）
   刚刚我们扩容的4台机器的服务器集群，现在只剩3台了，但是被缓存的数据的命中率只有1/3。

无论是扩容，还是缩容，这样的一个缓存命中率是不能被接受的。能不能通过改进路由算法，使得新加入的服务器不影响大部分缓存数据的正确命中呢？目前比较流行的算法是一致性Hash算法。

一致性Hash算法

一致性Hash算法通过一个叫作一致性Hash环的数据结构实现KEY到缓存服务器的Hash映射，如下图所示：

具体的算法过程为：
先构造一个长度为2³²的证书环，（这个环被称为一致性Hash环），根据节点名称的Hash之（其分布范围为[0,2³²-1]）将缓存服务器节点放置在这个Hash环上。然后根据需要缓存的数据的KEY值，计算得到其Hash值*（其分布范围也同样为[0,2³²-1]），然后再Hash环上顺时针查找距离这个KEY的Hash值最近的服务器节点，完成KEY到服务器Hash的映射查找。

当缓存服务器集群需要扩容的时候，只需要将新加入的节点名称的Hash值放入一致性Hash环中（图中的node5），由于KEY是顺时针查找距离最近的节点，因此新加入的节点只影响整个环中的一小段，也就是图中黄色圈出来的部分。
我们假设Hash算法使得服务器节点的Hash值在一致性Hash环上的分布很均匀，受影响的数据是新增节点沿着一致性Hash环逆时针查找到的第一个服务器节点，到新增节点，之间的KEY值受到影响，大概率情况下缓存数据的命中率高于25%。并且随着集群规模的扩展，命中缓存的数据比例会越来越高。

一致性Hash算法引入虚拟层节点

大概率？为什么我要说大概率呢？因为当一致性Hash环上的节点较少时，可能出现分布不均的情况，假设集群中只有两台服务器，1,2，并且他们的Hash值很接近，那么就会出现大部分的数据请求落在在了1号服务器，2号服务器只负责了小部分的数据请求，也就是数据请求倾斜的问题。

这个时候新增一个节点3号，受影响的KEY是2号节点和3号节点中间的KEY，从图中，我们可以看到这部分数据占据了环的大半，这个是我们不能接受。
那么缩容，或者节点宕机会是什么情况？按照我们原来的设想， 受影响的是失效节点沿着一致性Hash环逆时针查找到的第一个服务器节点，与失效节点之前的数据，这些数据将会落在，失效节点顺时针查找到的第一个节点，那么这个节点便要承担原本两个节点负担的请求，有可能会出现雪崩现象。具体可以参考博文：
https://blog.csdn.net/u013679744/article/details/79166256，这里就不再赘述了。那么，问题来了？怎么办呢？
听说计算机领域有句话：计算机的任何问题都可以通过增加一个虚拟层来解决。
可以将每台物理缓存服务器虚拟为一组虚拟缓存服务器，将虚拟服务器的Hash值放置在Hash环上，KEY在环上先找到虚拟服务器的节点，再得到物理服务器的信息。
虚拟节点的引入，不仅可以使得负载更加均衡，还能有效的避免雪崩效应，多个虚拟节点的存在，使得节点失效后，受影响的片段很小，一个节点的宕机，虽然会导致一致性Hash环上多处的虚拟节点消失，影响多处片段，但是这些片段上的数据可以均匀的分配到Hash环上不同的机器，有效避免雪崩效应。
那么在实践中，一台物理服务器虚拟为多少个虚拟服务器节点合适呢？《大型网站技术架构》一书中，给出的经验值是150，笔者也没有实验过，当然这个值应该根据具体情况具体分析。

手写实现一个简单的一致性Hash算法

Hash值的计算，我们可以使用HashCode，一致性Hash环我们可以使用sortedMap，构建一个hashServerMap，key就是hash值，value就是服务器的具体IP地址，那么顺时针查找第一台服务器，我们可以利用tailMap方法，取出hashServerMap 中Hash值大于当前节点的map，取map中的第一个值，如果这个Map为空，那么就可以取hashServerMap的第一个值。强调一点，这样的一个实现只是为了更好的理解一致性HASH算法的原理。

import java.util.SortedMap;
import java.util.TreeMap;
import java.util.UUID;

public class ConsistentHashWithVirtual {

    public static void main(String[] args) {
        //step1 初始化：把服务器节点IP的哈希值对应到哈希环上
        // 定义服务器ip
        String[] tomcatServers = new String[]{"123.111.0.0","123.101.3.1","111.20.35.2","123.98.26.3"};

        SortedMap<Integer,String> hashServerMap = new TreeMap<>();
     
        // 定义针对每个真实服务器虚拟出来几个节点
        int virtaulCount = 3;

        for(String tomcatServer: tomcatServers) {
            // 求出每一个ip的hash值，对应到hash环上，存储hash值与ip的对应关系
            int serverHash = Math.abs(tomcatServer.hashCode());
            // 存储hash值与ip的对应关系
            hashServerMap.put(serverHash,tomcatServer);
            
            // 处理虚拟节点
            for(int i = 0; i < virtaulCount; i++) {
                int virtualHash = Math.abs((tomcatServer + "#" + i).hashCode());
                hashServerMap.put(virtualHash,"----由虚拟节点"+ i  + "映射过来的请求："+ tomcatServer);
            }
        }

        //step2 针对客户端IP求出hash值
        // 定义客户端IP
        String[] clients = new String[]{"10.78.12.3","113.25.63.1","126.12.3.8"};
        for(String client : clients) {
            int clientHash = Math.abs(client.hashCode());
            //step3 针对客户端,找到能够处理当前客户端请求的服务器（哈希环上顺时针最近）
            // 根据客户端ip的哈希值去找出哪一个服务器节点能够处理（）
            SortedMap<Integer, String> integerStringSortedMap = hashServerMap.tailMap(clientHash);
            if(integerStringSortedMap.isEmpty()) {
                // 取哈希环上的顺时针第一台服务器
                Integer firstKey = hashServerMap.firstKey();
                System.out.println("==========>>>>客户端：" + client + " 被路由到服务器：" + hashServerMap.get(firstKey));
            }else{
                Integer firstKey = integerStringSortedMap.firstKey();
                System.out.println("==========>>>>客户端：" + client + " 被路由到服务器：" + hashServerMap.get(firstKey));
            }
        }
    }
}

Nginx中一致性Hash算法的应用

nginx是支持一致性Hash算法的负载均衡的，但是它没有自带该模块，需要我们进行安装。ngx_http_upstream_consistent_hash 模块，使⽤⼀个内部⼀致性hash算法来选择合适的后端节点。
该模块可以根据配置参数采取不同的⽅式将请求均匀映射到后端机器，
consistent_hash $remote_addr：可以根据客户端ip映射
consistent_hash $request_uri：根据客户端请求的uri映射
consistent_hash $args：根据客户端携带的参数进⾏映
（1）下载该模块： https://github.com/replay/ngx_http_consistent_hash
（2）将下载的压缩包上传到nginx服务器，并解压
（3）在nginx的源码目录，也就是安装nginx时候，解压后的那个文件夹，执行以下命令，第一个命令是安装配置该模块：

./configure —add-module=/root/ngx_http_consistent_hash-master
make
make install

（4）在nginx.conf中进行相应的配置：

upstream serverName {
	consistent_hash $request_uri;
	server 127.0.0.1：8080
	server 127.0.0.1：8081
}

一致性Hash算法在Redis集群Codis等的具体应用

未完，待续。。。

一致性Hash算法在Mysql分库分表中的应用

未完，待续。。。