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 来完成,这其中就涉及到了空间的分配和释放,主要经过以下五步:

为字典 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 的值。

将字典中的属性 rehashix 的值设置为 0,表示正在执行 rehash 操作。

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

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

将字典中的属性 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 是如何进行重新哈希的问题,最后了解了哈希对象的一些常用命令,并通过一些例子验证了本文的结论。

到此这篇关于Redis中哈希分布不均匀的解决办法的文章就介绍到这了,更多相关Redis 哈希分布不均匀内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • redis哈希类型_动力节点Java学院整理

    redis中的hash也是我们使用中的高频数据结构,它的构造基本上和编程语言中的HashTable,Dictionary大同小异,如果大家往后有什么逻辑需要用Dictionary存放的话,可以根据场景优先考虑下redis哦. 一:常用方法 只要是一个数据结构,最基础的永远是CURD,redis中的insert和update,永远只需要set来替代,比如下面的Hset,如下图: 就好像Java中的类和方法,知道传递一些啥参数就OK了,就比如要说的HSet,它的格式如下: 接下来我在CentOS里面

  • redis哈希和集合_动力节点Java学院整理

    Redis的哈希值是字符串字段和字符串值之间的映射,所以他们是表示对象的完美数据类型在Redis中的哈希值,可存储超过400十亿键值对. 例子 redis 127.0.0.1:6379> HMSET yiibai name "redis tutorial" description "redis basic commands for caching" likes 20 visitors 23000 OK redis 127.0.0.1:6379> HGET

  • Redis中哈希分布不均匀的解决办法

    Redis 是一个键值对数据库,其键是通过哈希进行存储的.整个 Redis 可以认为是一个外层哈希,之所以称为外层哈希,是因为 Redis 内部也提供了一种哈希类型,这个可以称之为内部哈希.当我们采用哈希对象进行数据存储时,对整个 Redis 而言,就经过了两层哈希存储. 哈希对象 哈希对象本身也是一个 key-value 存储结构,底层的存储结构也可以分为两种:ziplist(压缩列表) 和 hashtable(哈希表).这两种存储结构也是通过编码来进行区分: 编码属性 描述 object e

  • redis远程连接不上的解决办法

    目录 问题描述: 如图所示: 解决步骤: 步骤一:注释掉redis.window.conf文件中的bind属性设置. 步骤二:把protected-mode属性设置no 问题描述: redis远程服务端运行在192.168.3.90计算机上,客户端计算机(ip:192.168.3.110)通过redsi-cli.exe客户端工具连接时,没有反应,连接不上. 如图所示: 解决步骤: 步骤一:注释掉redis.window.conf文件中的bind属性设置. 如图所示: 步骤二:把protected

  • Java 使用JdbcTemplate 中的queryForList发生错误解决办法

    Java 使用JdbcTemplate 中的queryForList发生错误解决办法          在开发项目中遇到JdbcTemplate 中的queryForList发生错误,很是头疼,在网上找了相关资料,可以帮忙解决,这里记录下, 一.问题描述:  查询时使用JdbcTemplate 中的queryForList发生错误,如下: 查询方法如下: jdbcTemplate.queryForList(selectSql.toString(), entityClass) 查询sql如下: s

  • Python 爬虫之超链接 url中含有中文出错及解决办法

    Python 爬虫之超链接 url中含有中文出错及解决办法 python3.5 爬虫错误: UnicodeEncodeError: 'ascii' codec can't encode characters 这个错误是由于超链接中含有中文引起的,超链接默认是用ascii编码的,所以不能直接出现中文,若要出现中文, 解决方法如下: import urllib from urllib.request import urlopen link="http://list.jd.com/list.html?

  • Linux中虚拟机宕机之后解决办法

    Linux中虚拟机宕机之后解决办法 问题现象 一次意外操作,导致虚拟机无法启动,重启宿主操作系统也无效. 恢复方法 第一步: 删除原来建立的虚拟机. 第二步: 重新建立新虚拟机. 第三步: 在建立虚拟硬盘步骤,选择"使用已有的虚拟硬盘文件",该文件笔者为G:\vmdisk\Centos.vdi,在第一次建立虚拟机安装虚拟操作系统时时会创建该文件. 界面如下: 第四步: 虚拟机建立完成后,即可正常. 注意事项 1.定期备份G:\vmdisk\Centos.vdi虚拟硬盘文件是一个好习惯,

  • Android中ScrollView嵌套GridView的解决办法

    前些日子在开发中用到了需要ScrollView嵌套GridView的情况,由于这两款控件都自带滚动条,当他们碰到一起的时候便会出问题,即GridView会显示不全. 找到大家的通用解决办法.记录一下. 解决办法,自定义一个GridView控件 public class MyGridView extends GridView { public MyGridView(Context context, AttributeSet attrs) { super(context, attrs); } pub

  • Android中HTTP请求中文乱码解决办法

    Android中HTTP请求中文乱码解决办法 编码参数 List<NameValuePair> formparams = new ArrayList<NameValuePair>(); // 请求参数 for (NameValuePair p : params) { formparams.add(p); } UrlEncodedFormEntity entity = new UrlEncodedFormEntity(formparams,HTTP.UTF_8); // 创建POST

  • Android 中 android.view.WindowLeaked的解决办法

    Android 中 android.view.WindowLeaked的解决办法 按字面了解,Window Leaked大概就是说一个窗体泄漏了,也就是我们常说的内存泄漏,为什么窗体会泄漏呢? 产生原因: 我们知道Android的每一个Activity都有个WindowManager窗体管理器,同样,构建在某个Activity之上的对话框.PopupWindow也有相应的WindowManager窗体管理器.因为对话框.PopupWindown不能脱离Activity而单独存在着,所以当某个Di

  • 详解php中curl返回false的解决办法

    首先来看一个封装的curl函数 function request_post($url = '', $param = '') { if (empty($url) || empty($param)) { return false; } $postUrl = $url; $curlPost = $param; $curl = curl_init();//初始化curl curl_setopt($curl, CURLOPT_URL,$postUrl);//抓取指定网页 curl_setopt($curl

  • 详解mybatis-plus实体类中字段和数据库中字段名不对应解决办法

    在使用mybatis或者mybatis-plus时候,有些时候会出现数据库的字段名和实体类的字段名不一致的情况,如果运行那么这个字段就会无法进行自动映射而报错.这里就以我的数据库name字段名和这里的实体类的u_name字段名为例. 解决办法有以下三种 方法一: 将数据库中的字段和实体类中的字段名修改成一样的名字 方法二: 如果是自定以mapper.xml文件中手写的sql查询语句,可以给字段起一个别名例如这里就可以写成select name as u_name from- 方法三: 使用注解@

随机推荐