精华内容
下载资源
问答
  • GP提供了多种分布策略:哈希分布、随机分布和复制表。其中,最常用的就是哈希分布。本篇文章我将向大家介绍GP的哈希分布。首先,我们先回顾一下上篇文章用于调试的那张表: 大家可以看到建表语句末尾有DISTRIBUTEDBY...
  • Redis中哈希分布不均匀该怎么办

    千次阅读 多人点赞 2021-01-20 21:20:45
    Redis中哈希分布不均匀该怎么办 前言 哈希对象 hashtable 字典 rehash 操作 rehash 步骤 渐进式 rehash ziplist ziplist 和 hashtable 的编码转换 哈希对象常用命令 总结 前言 Redis 是一个键值对数据库,其键是通过...

    前言

    Redis 是一个键值对数据库,其键是通过哈希进行存储的。整个 Redis 可以认为是一个外层哈希,之所以称为外层哈希,是因为 Redis 内部也提供了一种哈希类型,这个可以称之为内部哈希。当我们采用哈希对象进行数据存储时,对整个 Redis 而言,就经过了两层哈希存储。

    哈希对象

    哈希对象本身也是一个 key-value 存储结构,底层的存储结构也可以分为两种:ziplist(压缩列表) 和 hashtable(哈希表)。这两种存储结构也是通过编码来进行区分:

    编码属性描述object encoding命令返回值
    OBJ_ENCODING_ZIPLIST使用压缩列表实现哈希对象ziplist
    OBJ_ENCODING_HT使用字典实现哈希对象hashtable

    hashtable

    Redis 中的 key-value 是通过 dictEntry 对象进行包装的,而哈希表就是将 dictEntry 对象又进行了再一次的包装得到的,这就是哈希表对象 dictht

    typedef struct dictht {
        dictEntry **table;//哈希表数组
        unsigned long size;//哈希表大小
        unsigned long sizemask;//掩码大小,用于计算索引值,总是等于size-1
        unsigned long used;//哈希表中的已有节点数
    } dictht;
    

    注意:上面结构定义中的 table 是一个数组,其每个元素都是一个 dictEntry 对象。

    字典

    字典,又称为符号表(symbol table),关联数组(associative array)或者映射(map),字典的内部嵌套了哈希表 dictht 对象,下面就是一个字典 ht 的定义:

    typedef struct dict {
        dictType *type;//字典类型的一些特定函数
        void *privdata;//私有数据,type中的特定函数可能需要用到
        dictht ht[2];//哈希表(注意这里有2个哈希表)
        long rehashidx; //rehash索引,不在rehash时,值为-1
        unsigned long iterators; //正在使用的迭代器数量
    } dict;
    

    其中 dictType 内部定义了一些常用函数,其数据结构定义如下:

    typedef struct dictType {
        uint64_t (*hashFunction)(const void *key);//计算哈希值函数
        void *(*keyDup)(void *privdata, const void *key);//复制键函数
        void *(*valDup)(void *privdata, const void *obj);//复制值函数
        int (*keyCompare)(void *privdata, const void *key1, const void *key2);//对比键函数
        void (*keyDestructor)(void *privdata, void *key);//销毁键函数
        void (*valDestructor)(void *privdata, void *obj);//销毁值函数
    } dictType;
    

    当我们创建一个哈希对象时,可以得到如下简图(部分属性被省略):

    在这里插入图片描述

    rehash 操作

    dict 中定义了一个数组 ht[2]ht[2] 中定义了两个哈希表:ht[0]ht[1]。而 Redis 在默认情况下只会使用 ht[0],并不会使用 ht[1],也不会为 ht[1] 初始化分配空间。

    当设置一个哈希对象时,具体会落到哈希数组(上图中的 dictEntry[3])中的哪个下标,是通过计算哈希值来确定的。如果发生哈希碰撞(计算得到的哈希值一致),那么同一个下标就会有多个 dictEntry,从而形成一个链表(上图中最右边指向 NULL 的位置),不过需要注意的是最后插入元素的总是落在链表的最前面(即发生哈希冲突时,总是将节点往链表的头部放)。

    当读取数据的时候遇到一个节点有多个元素,就需要遍历链表,故链表越长,性能越差。为了保证哈希表的性能,需要在满足以下两个条件中的一个时,对哈希表进行 rehash(重新散列)操作:

    • 负载因子大于等于 1dict_can_resize1 时。
    • 负载因子大于等于安全阈值(dict_force_resize_ratio=5)时。

    PS:负载因子 = 哈希表已使用节点数 / 哈希表大小(即:h[0].used/h[0].size)。

    rehash 步骤

    扩展哈希和收缩哈希都是通过执行 rehash 来完成,这其中就涉及到了空间的分配和释放,主要经过以下五步:

    1. 为字典 dictht[1] 哈希表分配空间,其大小取决于当前哈希表已保存节点数(即:ht[0].used):

      • 如果是扩展操作则 ht[1] 的大小为 2 的 n 次方中第一个大于等于 ht[0].used * 2 属性的值(比如 used=3,此时ht[0].used * 2=6,故 23 次方为 8 就是第一个大于 used * 2 的值(2 的 2 次方 < 6 且 2 的 3 次方 > 6))。`
      • 如果是收缩操作则 ht[1] 大小为 2 的 n 次方中第一个大于等于 ht[0].used 的值。
    2. 将字典中的属性 rehashix 的值设置为 0,表示正在执行 rehash 操作。

    3. ht[0] 中所有的键值对依次重新计算哈希值,并放到 ht[1] 数组对应位置,每完成一个键值对的 rehash之后 rehashix 的值需要自增 1

    4. ht[0] 中所有的键值对都迁移到 ht[1] 之后,释放 ht[0] ,并将 ht[1] 修改为 ht[0],然后再创建一个新的 ht[1] 数组,为下一次 rehash 做准备。

    5. 将字典中的属性 rehashix 设置为 -1,表示此次 rehash 操作结束,等待下一次 rehash

    渐进式 rehash

    Redis 中的这种重新哈希的操作因为不是一次性全部 rehash,而是分多次来慢慢的将 ht[0] 中的键值对 rehashht[1],故而这种操作也称之为渐进式 rehash。渐进式 rehash 可以避免集中式 rehash 带来的庞大计算量,是一种分而治之的思想。

    在渐进式 rehash 过程中,因为还可能会有新的键值对存进来,此时** Redis 的做法是新添加的键值对统一放入 ht[1] 中,这样就确保了 ht[0] 键值对的数量只会减少**。

    当正在执行 rehash操作时,如果服务器收到来自客户端的命令请求操作,则会先查询 ht[0],查找不到结果再到ht[1] 中查询

    ziplist

    关于 ziplist 的一些特性,之前的文章中有单独进行过分析,想要详细了解的,可以点击这里。但是需要注意的是哈希对象中的 ziplist 和列表对象中 ziplist 的有一点不同就是哈希对象是一个 key-value 形式,所以其 ziplist 中也表现为 key-valuekeyvalue 紧挨在一起:

    在这里插入图片描述

    ziplist 和 hashtable 的编码转换

    当一个哈希对象可以满足以下两个条件中的任意一个,哈希对象会选择使用 ziplist 编码来进行存储:

    • 哈希对象中的所有键值对总长度(包括键和值)小于等于 64字节(这个阈值可以通过参数 hash-max-ziplist-value 来进行控制)。
    • 哈希对象中的键值对数量小于等于 512 个(这个阈值可以通过参数 hash-max-ziplist-entries 来进行控制)。

    一旦不满足这两个条件中的任意一个,哈希对象就会选择使用 hashtable 编码进行存储。

    哈希对象常用命令

    • hset key field value:设置单个 field(哈希对象的 key 值)。
    • hmset key field1 value1 field2 value2 :设置多个 field(哈希对象的 key 值)。
    • hsetnx key field value:将哈希表 key 中域 field 的值设置为 value,如果 field 已存在,则不执行任何操作。
    • hget key field:获取哈希表 key 中的域 field 对应的 value
    • hmget key field1 field2:获取哈希表 key 中的多个域 field 对应的 value
    • hdel key field1 field2:删除哈希表 key 中的一个或者多个 field
    • hlen key:返回哈希表key中域的数量。
    • hincrby key field increment:为哈希表 key 中的域 field 的值加上增量 incrementincrement 可以为负数,如果 field 不是数字则会报错。
    • hincrbyfloat key field increment:为哈希表 key 中的域 field 的值加上增量 incrementincrement 可以为负数,如果 field 不是 float 类型则会报错。
    • hkeys key:获取哈希表 key 中的所有域。
    • hvals key:获取哈希表中所有域的值。

    了解了操作哈希对象的常用命令,我们就可以来验证下前面提到的哈希对象的类型和编码了,在测试之前为了防止其他 key 值的干扰,我们先执行 flushall 命令清空 Redis 数据库。

    然后依次执行如下命令:

    hset address country china
    type address
    object encoding address
    

    得到如下效果:

    在这里插入图片描述

    可以看到当我们的哈希对象中只有一个键值对的时候,底层编码是 ziplist

    现在我们将 hash-max-ziplist-entries 参数改成 2,然后重启 Redis,最后再输入如下命令进行测试:

    hmset key field1 value1 field2 value2 field3 value3
    object encoding key
    

    输出之后得到如下结果:

    在这里插入图片描述

    可以看到,编码已经变成了 hashtable

    总结

    本文主要介绍了 Redis5 种常用数据类型中的哈希类型底层的存储结构 hashtable 的使用,以及当 hash 分布不均匀时候 Redis 是如何进行重新哈希的问题,最后了解了哈希对象的一些常用命令,并通过一些例子验证了本文的结论。

    展开全文
  • 分布式系统的数据分布在多个节点中,常用的数据分布方式有哈希分布和顺序分布。 哈希分布 哈希分布就是将数据计算哈希值之后,按照哈希值分配到不同的节点上。例如有 N 个节点,数据的主键为 key,则将该数据分配的...

    分布式系统的数据分布在多个节点中,常用的数据分布方式有哈希分布和顺序分布。

    哈希分布

    哈希分布就是将数据计算哈希值之后,按照哈希值分配到不同的节点上。例如有 N 个节点,数据的主键为 key,则将该数据分配的节点序号为:hash(key)%N。
    传统的哈希分布算法存在一个问题:当节点数量变化时,也就是 N 值变化,那么几乎所有的数据都需要重新分布,将导致大量的数据迁移。

    一致性哈希:减少数据迁移

    Distributed Hash Table(DHT):对于哈希空间 0~2^n ,将该哈希空间看成一个哈希环,将每个节点都配置到哈希环上。每个数据对象通过哈希取模得到哈希值之后,存放到哈希环中顺时针方向第一个大于等于该哈希值的节点上。

    一致性哈希的优点:在加入或者删除节点时只会影响到哈希环中相邻的节点
    例如:增加了机器c4,只针对c3和c4之间的数据进行迁移,即将o4数据迁移到c4中。
    在这里插入图片描述

    虚拟节点:解决增加机器时负载不均衡

    一致性哈希解决了数据迁移量大的问题,但只是减轻了插入节点顺时针开始遇到的第一个机器负担,对于其他的节点并未起到减轻负载的作用。

    解决办法:引入虚拟节点。将每台物理机器虚拟为一组虚拟机器,放置在hash环上。对于每一个数据对象,首先按照顺时针查找第一个虚拟节点,再通过虚拟节点找到对应的物理节点。

    例如:插入节点4时,对应的一组虚拟节点是C41,C42,C43,减轻了C31,C22,C11的负担,实现了负载均衡
    在这里插入图片描述

    顺序分布

    哈希分布式破坏了数据的有序性,顺序分布则不会。
    顺序分布的数据划分为多个连续的部分,按一定策略分布到不同节点上。
    在这里插入图片描述
    User 表的主键范围为 1 ~ 7000,使用顺序分布可以将其划分成多个子表,对应的主键范围为 1 ~ 1000,1001 ~ 2000,…,6001 ~ 7000。
    其中 Meta 表是为了支持更大的集群规模,它将原来的一层索引结分成两层,使用 Meta 表来维护 User 子表所在的节点,从而减轻 Root 节点的负担。

    展开全文
  • 二十七、哈希分布

    2018-08-20 12:19:48
    哈希分布 1、节点取余分区 2、一致性哈希 顺时针分配 扩容只影响相连两个节点 3、虚拟槽分区 槽可以理解成一个数据集,他是有一定范围的。根据哈希函数计算key在哪个槽范围内。 所谓的虚拟槽分配:先对keys进行CRC16...

                                  哈希分布

    这里写图片描述

    这里写图片描述

    1、节点取余分区

    这里写图片描述

    这里写图片描述

    这里写图片描述

    这里写图片描述

    这里写图片描述


    2、一致性哈希

    顺时针分配

    这里写图片描述

    扩容只影响相连两个节点

    这里写图片描述

    这里写图片描述

    3、虚拟槽分区

    槽可以理解成一个数据集,他是有一定范围的。根据哈希函数计算key在哪个槽范围内。

    这里写图片描述

    所谓的虚拟槽分配:先对keys进行CRC16(key)函数计算在对16383进行取余。根据结果将发送给node-1到node-5每一个节点,当结果在哈希槽范围内就入节点。
    这里写图片描述

    展开全文
  • [转]哈希分布与一致性哈希算法简介

    千次阅读 2012-06-11 02:10:28
    哈希分布与一致性哈希算法简介 作者:liunx 来源:http://www.cnblogs.com/liunx/archive/2010/03/24/1693925.html  前言 在我们的日常web应用开发当中memcached可以算作是当今的标准开发配置了。相信...


    哈希分布与一致性哈希算法简介

    作者:liunx

    来源:http://www.cnblogs.com/liunx/archive/2010/03/24/1693925.html 

    前言
    在我们的日常web应用开发当中memcached可以算作是当今的标准开发配置了。相信memcache的基本原理大家也都了解过了,memcache虽然是分布式的应用服务,但分布的原则是由client端的api来决定的,api根据存储用的key以及已知的服务器列表,根据key的hash计算将指定的key存储到对应的服务器列表上。

    基本的原理以及分布
    在这里我们通常使用的方法是根据 key的hash值%服务器数取余数 的方法来决定当前这个key的内容发往哪一个服务器的。这里会涉及到一个hash算法的分布问题,哈希的原理用一句话解释就是两个集合间的映射关系函数,在我们通常的应用中基本上可以理解为 在集合A(任意字母数字等组合,此处为存储用的key)里的一条记录去查找集合B(如0-2^32)中的对应记录。(题外话:md5的碰撞或者说冲突其实就是发生在这里,也就是说多个A的记录映射到了同一个B的记录)

    实际应用
    显然在我们的应用中集合A的记录应该更均匀的分布在集合B的各个位置,这样才能尽量避免我们的数据被分布发送到单一的服务器上,在danga的memcached的原始版本(perl)中使用的是crc32的算法用java的实现写出来:
        private static int origCompatHashingAlg( String key ) {
            int hash    = 0;
            char[] cArr = key.toCharArray();

            for ( int i = 0; i < cArr.length; ++i ) {
                hash = (hash * 33) + cArr[i];
            }

            return hash;
        }
    这里还有另一个改进版本的算法:
        private static int newCompatHashingAlg( String key ) {
            CRC32 checksum = new CRC32();
            checksum.update( key.getBytes() );
            int crc = (int) checksum.getValue();

            return (crc >> 16) & 0x7fff;
        }

    分布率测试
    有人做过测试,随机选择的key在服务器数量为5的时候所有key在服务器群组上的分布概率是:
    origCompatHashingAlg:
    0 10%
    1 9%
    2 60%
    3 9%
    4 9%

    newCompatHashingAlg:
    0 19%
    1 19%
    2 20%
    3 20%
    4 20%

    显然使用旧的crc32算法会导致第三个memcached服务的负载更高,但使用新算法会让服务之间的负载更加均衡。
    其他常用的hash算法还有FNV-1a Hash,RS Hash,JS Hash,PJW Hash,ELF Hash,AP Hash等等。有兴趣的童鞋可以查看这里:

    http://www.partow.net/programming/hashfunctions/

    http://hi.baidu.com/algorithms/blog/item/79caabee879ece2a2cf53440.html

    小结
    至此我们了解到了在我们的应用当中要做到尽量让我们的映射更加均匀分布,可以使服务的负载更加合理均衡。

    新问题
    但到目前为止我们依然面对了这样一个问题:就是服务实例本身发生变动的时候,导致服务列表变动从而会照成大量的cache数据请求会miss,几乎大部分数据会需要迁移到另外的服务实例上。这样在大型服务在线时,瞬时对后端数据库/硬盘照成的压力很可能导致整个服务的crash。

    一致性哈希(Consistent Hashing)
    在此我们采用了一种新的方式来解决问题,处理服务器的选择不再仅仅依赖key的hash本身而是将服务实例(节点)的配置也进行hash运算。

    1. 首先求出每个服务节点的hash,并将其配置到一个0~2^32的圆环(continuum)区间上。
    2. 其次使用同样的方法求出你所需要存储的key的hash,也将其配置到这个圆环(continuum)上。
    3. 然后从数据映射到的位置开始顺时针查找,将数据保存到找到的第一个服务节点上。如果超过2^32仍然找不到服务节点,就会保存到第一个memcached服务节点上。

    整个数据的图例:


    当增加服务节点时:

    其他:只有在圆环上增加服务节点的位置为逆时针方向的第一个服务节点上的键会受到影响。

    小结
    一致性哈希算法最大程度的避免了key在服务节点列表上的重新分布,其他附带的改进就是有的一致性哈希算法还增加了虚拟服务节点的方法,也就是一个服务节点在环上有多个映射点,这样就能抑制分布不均匀,
    最大限度地减小服务节点增减时的缓存重新分布。

    应用
    在memcached的实际应用,虽然官方的版本并不支持Consistent Hashing,但是已经有了现实的Consistent Hashing实现以及虚节点的实现,第一个实现的是last.fm(国外流行的音乐平台)开发的libketama,
    其中调用的hash的部分的java版本的实现(基于md5):
        /**
         * Calculates the ketama hash value for a string
         * @param s
         * @return
         */
        public static Long md5HashingAlg(String key) {

            if(md5==null) {
                try {
                    md5 = MessageDigest.getInstance("MD5");
                } catch (NoSuchAlgorithmException e) {
                    log.error( "++++ no md5 algorythm found" );
                    throw new IllegalStateException( "++++ no md5 algorythm found");            
                }
            }

            md5.reset();
            md5.update(key.getBytes());
            byte[] bKey = md5.digest();
            long res = ((long)(bKey[3]&0xFF) << 24) | ((long)(bKey[2]&0xFF) << 16) | ((long)(bKey[1]&0xFF) << 8) | (long)(bKey[0]&0xFF);
            return res;
        }
    在一致性哈希的算法/策略环境中,按照测试来说时间和分布性都是综合来说比较让人满意的,参见:
    http://www.javaeye.com/topic/346682

    总结
    在我们的web开发应用中的分布式缓存系统里哈希算法承担着系统架构上的关键点。
    使用分布更合理的算法可以使得多个服务节点间的负载相对均衡,可以最大程度的避免资源的浪费以及服务器过载。
    使用一致性哈希算法,可以最大程度的降低服务硬件环境变化带来的数据迁移代价和风险。
    使用更合理的配置策略和算法可以使分布式缓存系统更加高效稳定的为我们整体的应用服务。

    展望
    一致性哈希的算法/策略来源于p2p网络,其实纵观p2p网络应用的场景,在许多地方与我们的应用有很多相似的地方,可以学习借鉴。
    参考文章:
    对等网络(P2P)中主流分布式哈希算法比较分析
    http://www.ppcn.net/n3443c38.aspx

    其他参考文章:
    http://www.taiwanren.com/blog/article.asp?id=840
    http://www.iwms.net/n923c43.aspx
    http://tech.idv2.com/2008/07/24/memcached-004/

    相关代码:
    last.fm的ketama代码
    http://static.last.fm/rj/ketama.tar.bz2

    php版的Consistent Hashing实现:Flexihash
    主页:
    http://paul.annesley.cc/articles/2008/04/flexihash-consistent-hashing-php
    google code上的代码主页:
    http://code.google.com/p/flexihash/
    现在已经移居到github上了:
    http://github.com/pda/flexihash/




    一致性 hash 算法( consistent hashing )

    作者:张亮

    来源:http://blog.csdn.net/sparkliang/article/details/5279393 


    consistent hashing 算法早在 1997 年就在论文 Consistent hashing and random trees 中被提出,目前在 cache 系统中应用越来越广泛;

    1 基本场景

    比如你有 N 个 cache 服务器(后面简称 cache ),那么如何将一个对象 object 映射到 N 个 cache 上呢,你很可能会采用类似下面的通用方法计算 object 的 hash 值,然后均匀的映射到到 N 个 cache ;

    hash(object)%N

    一切都运行正常,再考虑如下的两种情况;

    1 一个 cache 服务器 m down 掉了(在实际应用中必须要考虑这种情况),这样所有映射到 cache m 的对象都会失效,怎么办,需要把 cache m 从 cache 中移除,这时候 cache 是 N-1 台,映射公式变成了 hash(object)%(N-1) ;

    2 由于访问加重,需要添加 cache ,这时候 cache 是 N+1 台,映射公式变成了 hash(object)%(N+1) ;

    1 和 2 意味着什么?这意味着突然之间几乎所有的 cache 都失效了。对于服务器而言,这是一场灾难,洪水般的访问都会直接冲向后台服务器;

    再来考虑第三个问题,由于硬件能力越来越强,你可能想让后面添加的节点多做点活,显然上面的 hash 算法也做不到。

      有什么方法可以改变这个状况呢,这就是 consistent hashing...

    2 hash 算法和单调性

       Hash 算法的一个衡量指标是单调性( Monotonicity ),定义如下:

      单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中,又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去,而不会被映射到旧的缓冲集合中的其他缓冲区。

    容易看到,上面的简单 hash 算法 hash(object)%N 难以满足单调性要求。

    3 consistent hashing 算法的原理

    consistent hashing 是一种 hash 算法,简单的说,在移除 / 添加一个 cache 时,它能够尽可能小的改变已存在 key 映射关系,尽可能的满足单调性的要求。

    下面就来按照 5 个步骤简单讲讲 consistent hashing 算法的基本原理。

    3.1 环形hash 空间

    考虑通常的 hash 算法都是将 value 映射到一个 32 为的 key 值,也即是 0~2^32-1 次方的数值空间;我们可以将这个空间想象成一个首( 0 )尾( 2^32-1 )相接的圆环,如下面图 1 所示的那样。

    circle space

    图 1 环形 hash 空间

    3.2 把对象映射到hash 空间

    接下来考虑 4 个对象 object1~object4 ,通过 hash 函数计算出的 hash 值 key 在环上的分布如图 2 所示。

    hash(object1) = key1;

    … …

    hash(object4) = key4;

    object

    图 2 4 个对象的 key 值分布

    3.3 把cache 映射到hash 空间

    Consistent hashing 的基本思想就是将对象和 cache 都映射到同一个 hash 数值空间中,并且使用相同的hash 算法。

    假设当前有 A,B 和 C 共 3 台 cache ,那么其映射结果将如图 3 所示,他们在 hash 空间中,以对应的 hash值排列。

    hash(cache A) = key A;

    … …

    hash(cache C) = key C;

    cache

    图 3 cache 和对象的 key 值分布

     

    说到这里,顺便提一下 cache 的 hash 计算,一般的方法可以使用 cache 机器的 IP 地址或者机器名作为hash 输入。

    3.4 把对象映射到cache

    现在 cache 和对象都已经通过同一个 hash 算法映射到 hash 数值空间中了,接下来要考虑的就是如何将对象映射到 cache 上面了。

    在这个环形空间中,如果沿着顺时针方向从对象的 key 值出发,直到遇见一个 cache ,那么就将该对象存储在这个 cache 上,因为对象和 cache 的 hash 值是固定的,因此这个 cache 必然是唯一和确定的。这样不就找到了对象和 cache 的映射方法了吗?!

    依然继续上面的例子(参见图 3 ),那么根据上面的方法,对象 object1 将被存储到 cache A 上; object2和 object3 对应到 cache C ; object4 对应到 cache B ;

    3.5 考察cache 的变动

    前面讲过,通过 hash 然后求余的方法带来的最大问题就在于不能满足单调性,当 cache 有所变动时,cache 会失效,进而对后台服务器造成巨大的冲击,现在就来分析分析 consistent hashing 算法。

    3.5.1 移除 cache

    考虑假设 cache B 挂掉了,根据上面讲到的映射方法,这时受影响的将仅是那些沿 cache B 逆时针遍历直到下一个 cache ( cache C )之间的对象,也即是本来映射到 cache B 上的那些对象。

    因此这里仅需要变动对象 object4 ,将其重新映射到 cache C 上即可;参见图 4 。

    remove

    图 4 Cache B 被移除后的 cache 映射

    3.5.2 添加 cache

    再考虑添加一台新的 cache D 的情况,假设在这个环形 hash 空间中, cache D 被映射在对象 object2 和object3 之间。这时受影响的将仅是那些沿 cache D 逆时针遍历直到下一个 cache ( cache B )之间的对象(它们是也本来映射到 cache C 上对象的一部分),将这些对象重新映射到 cache D 上即可。

     

    因此这里仅需要变动对象 object2 ,将其重新映射到 cache D 上;参见图 5 。

    add

    图 5 添加 cache D 后的映射关系

    4 虚拟节点

    考量 Hash 算法的另一个指标是平衡性 (Balance) ,定义如下:

    平衡性

      平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去,这样可以使得所有的缓冲空间都得到利用。

    hash 算法并不是保证绝对的平衡,如果 cache 较少的话,对象并不能被均匀的映射到 cache 上,比如在上面的例子中,仅部署 cache A 和 cache C 的情况下,在 4 个对象中, cache A 仅存储了 object1 ,而 cache C 则存储了 object2 、 object3 和 object4 ;分布是很不均衡的。

    为了解决这种情况, consistent hashing 引入了“虚拟节点”的概念,它可以如下定义:

    “虚拟节点”( virtual node )是实际节点在 hash 空间的复制品( replica ),一实际个节点对应了若干个“虚拟节点”,这个对应个数也成为“复制个数”,“虚拟节点”在 hash 空间中以 hash 值排列。

    仍以仅部署 cache A 和 cache C 的情况为例,在图 4 中我们已经看到, cache 分布并不均匀。现在我们引入虚拟节点,并设置“复制个数”为 2 ,这就意味着一共会存在 4 个“虚拟节点”, cache A1, cache A2 代表了 cache A ; cache C1, cache C2 代表了 cache C ;假设一种比较理想的情况,参见图 6 。

    virtual nodes

    图 6 引入“虚拟节点”后的映射关系

     

    此时,对象到“虚拟节点”的映射关系为:

    objec1->cache A2 ; objec2->cache A1 ; objec3->cache C1 ; objec4->cache C2 ;

    因此对象 object1 和 object2 都被映射到了 cache A 上,而 object3 和 object4 映射到了 cache C 上;平衡性有了很大提高。

    引入“虚拟节点”后,映射关系就从 { 对象 -> 节点 } 转换到了 { 对象 -> 虚拟节点 } 。查询物体所在 cache时的映射关系如图 7 所示。

    map

    图 7 查询对象所在 cache

     

    “虚拟节点”的 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

    5 小结

    Consistent hashing 的基本原理就是这些,具体的分布性等理论分析应该是很复杂的,不过一般也用不到。

    http://weblogs.java.net/blog/2007/11/27/consistent-hashing 上面有一个 java 版本的例子,可以参考。

    http://blog.csdn.net/mayongzhan/archive/2009/06/25/4298834.aspx 转载了一个 PHP 版的实现代码。

    http://www.codeproject.com/KB/recipes/lib-conhash.aspx C语言版本


     

    一些参考资料地址:

    http://portal.acm.org/citation.cfm?id=258660

    http://en.wikipedia.org/wiki/Consistent_hashing

    http://www.spiteful.com/2008/03/17/programmers-toolbox-part-3-consistent-hashing/

     http://weblogs.java.net/blog/2007/11/27/consistent-hashing

    http://tech.idv2.com/2008/07/24/memcached-004/

    http://blog.csdn.net/mayongzhan/archive/2009/06/25/4298834.aspx



    展开全文
  • 总结 本文主要介绍了 Redis 中 5 种常用数据类型中的哈希类型底层的存储结构 hashtable 的使用,以及当 hash 分布不均匀时候 Redis 是如何进行重新哈希的问题,最后了解了哈希对象的一些常用命令,并通过一些例子...
  • 数据分布设计原则 数据分布,主要就是数据分片,它解决了确定数据位置的问题。假设,现在有上百 G 数据需要进行分布式存储,也就是要存储到不同的节点上。要实现数据分布其实有很多种方法,比如随机分布、范围分布、...
  • 哈希分布与一致性哈希算法简介

    千次阅读 2011-07-19 15:37:33
    前言 在我们的日常web应用开发当中memcached...相信memcache的基本原理大家也都了解过了,memcache虽然是分布式的应用服务,但分布的原则是由client端的api来决定的,api根据存储用的key以及已知的服务器列表,根据key
  • 功能点: •DDL支持指定多个列作为哈希列 •DML支持多列哈希表 •集群查询支持多列哈系表 •集群加载支持多列哈希表 ...•使用uint32保存CRC32的值,如果多个CRC32值相加越界,不影响数据分布。 ...
  • 一致性哈希

    2018-10-24 14:26:06
    * 有两种方案,第一种普通hash分布,第二种一致性哈希分布 * * 普通hash分布 * 首先将key处理为一个32位字符串,取前8位,在经过hash计算处理成整数并返回,然后映射到其中一台服务器 * $servers[$this->...
  • 哈希表概述

    千次阅读 2018-05-22 21:46:50
    一、什么是哈希表? &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;哈希表(Hash table,也叫散列表),是根据关键码值(Key value)而直接进行访问的数据结构。也就是说,它通过把关键...
  • 在研究swift的基本原理时,看到了这个算法,不怎么明白,找了几个帖子来学习。...相信memcache的基本原理大家也都了解过了,memcache虽然是分布式的应用服务,但分布的原则是由client端的api来决定的,ap
  • 相信memcache的基本原理大家也都了解过了,memcache虽然是分布式的应用服务,但分布的原则是由client端的api来决定的,api根据存储用的key以及已知的服务器列表,根据key的hash计算将指定的key存储到对应的服务器...
  • Greenplum数据分布和分区策略

    千次阅读 2019-11-25 15:48:49
    Greenplum数据分布和分区策略 Greenplum是一个大规模并行处理数据库,它由一个master和多个segment组成,其数据按照设定的分布策略分布于各个segment上。数据表的单个行会被分配到一个或多个segment上,但是有这么...
  • python 哈希(hash)

    千次阅读 2019-08-20 15:20:40
    python 哈希(hash) 散列表(Hash table)–哈希表 基于高度存取 ,一种典型的“空间换时间” 可以理解为一个线性表,其中元素不是紧密排列,可能存在空隙 散列表,依据关键码值(key value)而进行访问的数据结构,...
  • 哈希分布 数据分散度高 键值分布业务无关 无法顺序访问 支持批量操作 一致性哈希Memcache Redis Cluster 其他缓存 顺序分布 数据分散度易倾斜 键值...
  • 整个Redis可以认为是一个外层哈希,之所以称为外层哈希,是因为Redis内部也提供了一种哈希类型,这个可以称之为内部哈希。当我们采用哈希对象进行数据存储时,对整个Redis而言,就经过了两层哈希存储。 哈希对象 ...
  • Redis的哈希槽介绍

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 68,284
精华内容 27,313
关键字:

哈希分布