算法（二）：一致性哈希算法的原理与实现

最新推荐文章于 2022-09-09 15:03:41 发布
最新推荐文章于 2022-09-09 15:03:41 发布
阅读量392 收藏
点赞数
分类专栏： 数据结构与算法
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/XiaoHanZuoFengZhou/article/details/103462211
版权

1 概述
1.1 传统哈希(硬哈希)
分布式系统中，假设有 n 个节点，传统方案使用 mod(key, n) 映射数据和节点。
当扩容或缩容时(哪怕只是增减1个节点)，映射关系变为 mod(key, n+1) / mod(key, n-1)，绝大多数数据的映射关系都会失效。

1.2 一致性哈希(Consistent Hashing)
1997年，麻省理工学院(MIT)的 David Karger 等6个人发布学术论文《Consistent hashing and random trees: distributed caching protocols for relieving hot spots on the World Wide Web（一致性哈希和随机树：用于缓解万维网上热点的分布式缓存协议）》，对于 K 个关键字和 n 个槽位(分布式系统中的节点)的哈希表，增减槽位后，平均只需对 K/n 个关键字重新映射。

1.3 哈希指标
评估一个哈希算法的优劣，有如下指标，而一致性哈希全部满足：

均衡性(Balance)：将关键字的哈希地址均匀地分布在地址空间中，使地址空间得到充分利用，这是设计哈希的一个基本特性。
单调性(Monotonicity): 单调性是指当地址空间增大时，通过哈希函数所得到的关键字的哈希地址也能映射的新的地址空间，而不是仅限于原先的地址空间。或等地址空间减少时，也是只能映射到有效的地址空间中。简单的哈希函数往往不能满足此性质。
分散性(Spread): 哈希经常用在分布式环境中，终端用户通过哈希函数将自己的内容存到不同的缓冲区。此时，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。
负载(Load): 负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。
1.4 资料链接
原始论文《Consistent Hashing and Random Trees》链接如下：

官方链接 - PDF 版本
本站副本 - PDF 版本
相关论文《Web Caching with Consistent Hashing》链接如下：

官方链接 - PDF 版本
官方链接 - HTM 版本
本站副本 - PDF 版本
更多资料：
WikiPedia - Consistent hashing
codeproject - Consistent hashing

2 算法原理
2.1 映射方案


2.1.1 公用哈希函数和哈希环
设计哈希函数 Hash(key)，要求取值范围为 [0, 2^32)
各哈希值在上图 Hash 环上的分布：时钟12点位置为0，按顺时针方向递增，临近12点的左侧位置为2^32-1。

2.1.2 节点(Node)映射至哈希环
如图哈希环上的绿球所示，四个节点 Node A/B/C/D，
其 IP 地址或机器名，经过同一个 Hash() 计算的结果，映射到哈希环上。

2.1.3 对象(Object)映射于哈希环
如图哈希环上的黄球所示，四个对象 Object A/B/C/D，
其键值，经过同一个 Hash() 计算的结果，映射到哈希环上。

2.1.4 对象(Object)映射至节点(Node)
在对象和节点都映射至同一个哈希环之后，要确定某个对象映射至哪个节点，
只需从该对象开始，沿着哈希环顺时针方向查找，找到的第一个节点，即是。
可见，Object A/B/C/D 分别映射至 Node A/B/C/D。

2.2 删除节点
现实场景：服务器缩容时删除节点，或者有节点宕机。如下图，要删除节点 Node C：
只会影响欲删除节点(Node C)与上一个(顺时针为前进方向)节点(Node B)与之间的对象，也就是 Object C，
这些对象的映射关系，按照 2.1.4 的规则，调整映射至欲删除节点的下一个节点 Node D。
其他对象的映射关系，都无需调整。


2.3 增加节点
现实场景：服务器扩容时增加节点。比如要在 Node B/C 之间增加节点 Node X：
只会影响欲新增节点(Node X)与上一个(顺时针为前进方向)节点(Node B)与之间的对象，也就是 Object C，
这些对象的映射关系，按照 2.1.4 的规则，调整映射至新增的节点 Node X。
其他对象的映射关系，都无需调整。


2.4 虚拟节点
对于前面的方案，节点数越少，越容易出现节点在哈希环上的分布不均匀，导致各节点映射的对象数量严重不均衡(数据倾斜)；相反，节点数越多越密集，数据在哈希环上的分布就越均匀。
但实际部署的物理节点有限，我们可以用有限的物理节点，虚拟出足够多的虚拟节点(Virtual Node)，最终达到数据在哈希环上均匀分布的效果：
如下图，实际只部署了2个节点 Node A/B，
每个节点都复制成3倍，结果看上去是部署了6个节点。
可以想象，当复制倍数为 2^32 时，就达到绝对的均匀，通常可取复制倍数为32或更高。
虚拟节点哈希值的计算方法调整为：对“节点的IP(或机器名)+虚拟节点的序号(1~N)”作哈希。


3 算法实现
一致性哈希算法有多种具体的实现，包括 Chord 算法，KAD 算法等，都比较复杂。
这里给出一个简易实现及其演示，可以看到一致性哈希的均衡性和单调性的优势。
单调性在本例中没有统计数据，但根据前面原理可知，增删节点后只有很少量的数据需要调整映射关系。

3.1 源码
/**
 * @author: https://kefeng.wang
 * @date: 2018-08-10 11:08
 **/
public class ConsistentHashing {
    // 物理节点
    private Set<String> physicalNodes = new TreeSet<String>() {
        {
            add("192.168.1.101");
            add("192.168.1.102");
            add("192.168.1.103");
            add("192.168.1.104");
        }
    };

    //虚拟节点
    private final int VIRTUAL_COPIES = 1048576; // 物理节点至虚拟节点的复制倍数
    private TreeMap<Long, String> virtualNodes = new TreeMap<>(); // 哈希值 => 物理节点

    // 32位的 Fowler-Noll-Vo 哈希算法
    // https://en.wikipedia.org/wiki/Fowler–Noll–Vo_hash_function
    private static Long FNVHash(String key) {
        final int p = 16777619;
        Long hash = 2166136261L;
        for (int idx = 0, num = key.length(); idx < num; ++idx) {
            hash = (hash ^ key.charAt(idx)) * 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;
    }

    // 根据物理节点，构建虚拟节点映射表
    public ConsistentHashing() {
        for (String nodeIp : physicalNodes) {
            addPhysicalNode(nodeIp);
        }
    }

    // 添加物理节点
    public void addPhysicalNode(String nodeIp) {
        for (int idx = 0; idx < VIRTUAL_COPIES; ++idx) {
            long hash = FNVHash(nodeIp + "#" + idx);
            virtualNodes.put(hash, nodeIp);
        }
    }

    // 删除物理节点
    public void removePhysicalNode(String nodeIp) {
        for (int idx = 0; idx < VIRTUAL_COPIES; ++idx) {
            long hash = FNVHash(nodeIp + "#" + idx);
            virtualNodes.remove(hash);
        }
    }

    // 查找对象映射的节点
    public String getObjectNode(String object) {
        long hash = FNVHash(object);
        SortedMap<Long, String> tailMap = virtualNodes.tailMap(hash); // 所有大于 hash 的节点
        Long key = tailMap.isEmpty() ? virtualNodes.firstKey() : tailMap.firstKey();
        return virtualNodes.get(key);
    }

    // 统计对象与节点的映射关系
    public void dumpObjectNodeMap(String label, int objectMin, int objectMax) {
        // 统计
        Map<String, Integer> objectNodeMap = new TreeMap<>(); // IP => COUNT
        for (int object = objectMin; object <= objectMax; ++object) {
            String nodeIp = getObjectNode(Integer.toString(object));
            Integer count = objectNodeMap.get(nodeIp);
            objectNodeMap.put(nodeIp, (count == null ? 0 : count + 1));
        }

        // 打印
        double totalCount = objectMax - objectMin + 1;
        System.out.println("======== " + label + " ========");
        for (Map.Entry<String, Integer> entry : objectNodeMap.entrySet()) {
            long percent = (int) (100 * entry.getValue() / totalCount);
            System.out.println("IP=" + entry.getKey() + ": RATE=" + percent + "%");
        }
    }

    public static void main(String[] args) {
        ConsistentHashing ch = new ConsistentHashing();

        // 初始情况
        ch.dumpObjectNodeMap("初始情况", 0, 65536);

        // 删除物理节点
        ch.removePhysicalNode("192.168.1.103");
        ch.dumpObjectNodeMap("删除物理节点", 0, 65536);

        // 添加物理节点
        ch.addPhysicalNode("192.168.1.108");
        ch.dumpObjectNodeMap("添加物理节点", 0, 65536);
    }
}

3.2 复制倍数为 1 时的均衡性
修改代码中 VIRTUAL_COPIES = 1(相当于没有虚拟节点)，运行结果如下(可见各节点负荷很不均衡)：

======== 初始情况 ========
IP=192.168.1.101: RATE=45%
IP=192.168.1.102: RATE=3%
IP=192.168.1.103: RATE=28%
IP=192.168.1.104: RATE=22%
======== 删除物理节点 ========
IP=192.168.1.101: RATE=45%
IP=192.168.1.102: RATE=3%
IP=192.168.1.104: RATE=51%
======== 添加物理节点 ========
IP=192.168.1.101: RATE=45%
IP=192.168.1.102: RATE=3%
IP=192.168.1.104: RATE=32%
IP=192.168.1.108: RATE=18%

3.2 复制倍数为 32 时的均衡性
修改代码中 VIRTUAL_COPIES = 32，运行结果如下(可见各节点负荷比较均衡)：

======== 初始情况 ========
IP=192.168.1.101: RATE=29%
IP=192.168.1.102: RATE=21%
IP=192.168.1.103: RATE=25%
IP=192.168.1.104: RATE=23%
======== 删除物理节点 ========
IP=192.168.1.101: RATE=39%
IP=192.168.1.102: RATE=37%
IP=192.168.1.104: RATE=23%
======== 添加物理节点 ========
IP=192.168.1.101: RATE=35%
IP=192.168.1.102: RATE=20%
IP=192.168.1.104: RATE=23%
IP=192.168.1.108: RATE=20%

3.2 复制倍数为 1M 时的均衡性
修改代码中 VIRTUAL_COPIES = 1048576，运行结果如下(可见各节点负荷非常均衡)：

======== 初始情况 ========
IP=192.168.1.101: RATE=24%
IP=192.168.1.102: RATE=24%
IP=192.168.1.103: RATE=25%
IP=192.168.1.104: RATE=25%
======== 删除物理节点 ========
IP=192.168.1.101: RATE=33%
IP=192.168.1.102: RATE=33%
IP=192.168.1.104: RATE=33%
======== 添加物理节点 ========
IP=192.168.1.101: RATE=25%
IP=192.168.1.102: RATE=24%
IP=192.168.1.104: RATE=24%
IP=192.168.1.108: RATE=24%

4 应用
一致性哈希是分布式系统组件负载均衡的首选算法，它既可以在客户端实现，也可以在中间件上实现。其应用有：

分布式散列表(DHT)的设计；
分布式关系数据库(MySQL)：分库分表时，计算数据与节点的映射关系；
分布式缓存：Memcached 的客户端实现了一致性哈希，还可以使用中间件 twemproxy 管理 redis/memcache 集群；
RPC 框架 Dubbo：用来选择服务提供者；
亚马逊的云存储系统 Dynamo；
分布式 Web 缓存；
Bittorrent DHT；
LVS。
 

晓寒风骤
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
python 实现 一致性哈希算法
04-19
一致性哈希算法
Fowler-Noll-Vo hash算法（FNV）---学习笔记
oneself的博客
08-29 382
Fowler-Noll-Vo hash算法（FNV）---学习笔记
一致性哈希算法原理详解
热门推荐
张维鹏的博客
10-17 4万+
（1）一致性哈希算法将整个哈希值空间按照顺时针方向组织成一个虚拟的圆环，称为 Hash 环； （2）接着将各个服务器使用 Hash 函数进行哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，从而确定每台机器在哈希环上的位置； （3）最后使用算法定位数据访问到相应服务器：将数据key使用相同的函数Hash计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针寻找，第一台遇到的服务器就是其应该定位到的服务器
一致性Hash算法原理详解
tiantian929的博客
02-25 933
一致性Hash算法原理详解
【GIS新探索】GeoHash原理和编解码实现
weixin_34279579的博客
07-18 532
1.什么是GeoHash geohash基本原理是将地球理解为一个二维平面，将平面递归分解成更小的子块，每个子块在一定经纬度范围内拥有相同的编码。不好理解，没关系，我来找个图。 就像上面这张图，一个坐标点，可以当做一个小格子，而格子的标注就是该坐标点geohash值，当然格子越小精度越高，这个看实际应用吧。 2.为什么要...
【GIS】geohash原理与实现
煎饼加鸡丝
07-31 3159
参考：https://www.cnblogs.com/LBSer/p/3310455.html https://en.wikipedia.org/wiki/Geohash 引子 考虑一个问题，如何搜索某点附近一定范围内的满足要求的公交站。 (截了个高德的图、并不知道高德地图后台如何搜索的。。。) 无脑思路：把所有的公交站和当前位置都算距离筛选 简单思路：把当前城市/附近行政...
PHP实现的一致性哈希算法完整实例
12-19
本文实例讲述了PHP实现的一致性哈希算法。分享给大家供大家参考，具体如下： <?php /** * Flexihash - A simple consistent hashing implementation for PHP. * * The MIT License * * Copyright (c) 2008 ...
一致性哈希算法 consistent hashing
04-11
在分布式系统中，常常需要使用缓存，而且通常是集群，访问缓存和添加缓存都需要一个 hash 算法来寻找到合适的 Cache 节点。但，通常不是用取余hash，而是使用我们今天的主角—— 一致性 hash 算法。
白话解析：一致性哈希算法1
08-03
白话解析：一致性哈希算法1
12-一致性哈希分布式算法原理与实现.wmv
02-13
12-一致性哈希分布式算法原理与实现.wmv
线性哈希-line hash
jackydai987的专栏
08-09 1万+
线性哈希   线性哈希是一种动态扩展哈希表的方法。 线性哈希的数学原理: 假定key = 5 、 9 、13 key % 4 = 1 现在我们对8求余 5 % 8 = 5 9 % 8=1 13 % 8 = 5 由上面的规律可以得出 (任意key) % n =
一致性Hash算法原理
u010988549的专栏
02-26 520
一、前言 在解决分布式系统中负载均衡的问题时候可以使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡的作用。 但是普通的余数hash（hash(比如用户id)%服务器机器数）算法伸缩性很差，当新增或者下线服务器机器时候，用户id与服务器的映射关系会大量失效。一致性hash则利用hash环对其进行了改进。 二、一致性Ha...
数据结构——一致性哈希
shintyan的博客
03-02 312
一、概述 （1） 传统哈希(硬哈希) 分布式系统中，假设有 n 个节点，传统方案使用 mod(key, n) 映射数据和节点。 当扩容或缩容时(哪怕只是增减1个节点)，映射关系变为 mod(key, n+1) / mod(key, n-1)，绝大多数数据的映射关系都会失效。 （2）一致性哈希(Consistent Hashing) 1997年，麻省理工学院(MIT)的 David Karger 等6个人发布学术论文《Consistent hashing...
一致性Hash(Consistent Hashing)原理剖析
Leo的博客
01-08 2万+
引入在业务开发中，我们常把数据持久化到数据库中。如果需要读取这些数据，除了直接从数据库中读取外，为了减轻数据库的访问压力以及提高访问速度，我们更多地引入缓存来对数据进行存取。读取数据的过程一般为： 图1：加入缓存的数据读取过程对于分布式缓存，不同机器上存储不同对象的数据。为了实现这些缓存机器的负载均衡，可以使用式子1来定位对象缓存的存储机器： m = hash(o) mod n ——式子
分布式原理：一致性哈希算法简介
lixiaoxiong的专栏
02-13 872
本文转自：https://www.iteblog.com/archives/2499.html 一致性哈希算法（Consistent Hashing）最早在1997年由 David Karger 等人在论文《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on t...
了解一致性hash原理，这篇文章就够了
浪丶荡
09-09 329
在理解一致性hash算法之前，让我们来看一个在缓存中最经典的案例场景，理解这个运用场景之后，我们再去理解一致性hash算法就更容易了，在这个过程中我们还能体会一致性hash算法的优势之处，好了，让我们来描述一下这个经典的分布式缓存案例。
理解一致性哈希算法的原理
Zach的博客
08-20 769
1. 什么是一致性哈希 一致性哈希算法核心思想,就是通过构造一个长度为2^32的整数环,这个环也被称为一致性Hash环(只是逻辑上的环),将缓存服务器的节点名称的哈希值均匀的分布在[0,2^32-1]的Hash环上,然后根据需要缓存的Key值计算得到其Hash值,然后在Hash环上顺时针查找距离Key的Hash值最近的服务器节点,完成Key到服务器的映射查找;如下图所示 2. 一致性哈希解决了什么问题 Hash算法解决的是集群管理中请求访问的路由的问题,一般是根据一个请求的某个key值取余,路由到
图解一致性哈希算法的基本原理
skh2015java的博客
12-12 1154
一致性哈希的基本原理 一致性哈希算法是将每个Node节点映射到同一个圆上。将各Node的key采用hash计算，可得到一个整数数组。将该数组排序后，首尾相连即是一个圆。如下图所示 简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0-2^32-1（即哈希值是一个32位无符号整形），整个哈希环如下： 整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、5、6……直到2^32-1，也就是说0点左侧..
一致性 hash 算法
Mergades
08-13 213
参考列表 理论分析： https://www.cnblogs.com/lpfuture/p/5796398.html 理论分析： https://blog.csdn.net/sparkliang/article/details/5279393 算法实现： https://www.cnblogs.com/xrq730/p/5186728.html memcache的一致性hash算法...
使用分布式事务或者使用一致性哈希算法实现具体怎么实现
最新发布
06-09
以下是使用分布式事务或者一致性哈希算法实现 Redis Sharding 分片的具体实现方法： 1. 使用分布式事务实现 在使用分布式事务实现 Redis Sharding 分片时，需要使用分布式事务框架（例如，XA、TCC 等）对多个 Redis 实例中的数据进行操作，以保证数据的一致性。具体实现步骤如下： - 将 Redis 实例分成多个片段，每个片段存储在一个 Redis 节点上。 - 对于每个操作，例如写操作或者删除操作，需要在多个 Redis 节点上开启一个分布式事务。 - 在分布式事务中，对于每个 Redis 节点执行相应的操作，例如写入数据或者删除数据。 - 如果所有节点的操作都执行成功，则提交分布式事务，否则回滚分布式事务。 需要注意的是，使用分布式事务实现 Redis Sharding 分片需要考虑如下问题： - 分布式事务的效率较低，会影响 Redis 的性能。 - 分布式事务需要协调多个节点的操作，容易出现死锁和性能瓶颈等问题。 - 分布式事务的实现需要依赖于分布式事务框架，需要额外的开发工作。 2. 使用一致性哈希算法实现 在使用一致性哈希算法实现 Redis Sharding 分片时，需要将数据分散存储在多个 Redis 节点上，并通过一致性哈希算法确定数据应该存储在哪个节点上。具体实现步骤如下： - 将 Redis 实例分成多个片段，每个片段存储在一个 Redis 节点上。 - 对于每个写操作或者查询操作，通过一致性哈希算法确定数据应该存储在哪个节点上。 - 如果要增加或删除节点，可以在一致性哈希算法中添加或删除节点，从而实现动态扩展或缩减 Redis 的容量。 需要注意的是，使用一致性哈希算法实现 Redis Sharding 分片需要考虑如下问题： - 一致性哈希算法可能会导致数据不均衡的问题，需要使用虚拟节点或者增加数据复制等技术解决。 - 一致性哈希算法需要考虑节点故障和数据恢复问题，通常使用主从复制或者集群化技术实现。 - 一致性哈希算法需要考虑节点的负载均衡问题，通常使用预取数据等技术解决。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值