你的位置:BOB(中国)官方入口-BOB综合官方入口 > BOB.COM > BOB.COM Redis源码之Hash组织的实现
BOB.COM Redis源码之Hash组织的实现
发布日期:2021-10-06 12:34    点击次数:122

本文转载自微信公多号「程序员幼饭」,作者饭米粒。转载本文请有关程序员幼饭公多号。

redis的hash的基本命令一时先不多说BOB.COM,吾们直接步入正文在redis的hash组织中,存在云云一栽形象

127.0.0.1:6379> hset user:001 name john age 25 sex man  "man" 

吾们先给user:001别离竖立了name,age,sex属性,然后经过hgetall获取所有属性,这总共望首还比较平常但是接下

127.0.0.1:6379> hset user:002 name john age 25 sex man extra xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  "25" 

吾们给user:002多竖立了一个extra属性,并且竖立的值比较大,然后用hgetall获取所有属性的时候发现返回的挨次不是遵命吾们竖立的时候的属性的挨次了,这是为什么呢?

其实主要因为是:hash数据组织底层实现为一个字典,也是redisDb用存储k-v的数据组织BOB.COM,当数据量比较幼,或者单个元素比较幼的时候,底层用ziplist存储,数据大幼和元素数目阈值能够经过如下参数竖立

hash-max-ziplist-entries512//ziplist元素个数超过512,将改为hashtable码hash-max-ziplist-value64//单个元素大幼超过64byte时,BOB.COM将改为hashtable码对于上面的例子主要是由于单个元素大幼超过了64byte因此改为了hashtable码导致了hgetall获取属性的时候和竖立的挨次纷歧样

压缩外的组织

其实许多同学也有一个疑问hash和string类型到底有啥内心的不同?其实吾们从源码能够望出对于string类型说string类型是基于RedisDb的倘若string的数目一向的变多就会导致dictht片面一向的rehash

而对于hash类型的说hash不存在dictht一向rehash的题目

但是其实也是各有利弊比如hash就没法对某个key竖立过期时间而且redis中有一个很大的隐讳就是不要让某个key过大容易壅塞因此幼我照样更保举string的手段

大型企业新闻化ERP平台项现在课程第一季 超周详Redis分布式高可用方案:哨兵机制 Redis很屌不懂行使规范就践踏了 聊聊Redis分布式锁的八大坑 教你如何让Redis更持久!