Redis远程字典服务器 hash类型示例详解

目录

• 一，hash基本情况
• 二，hash常用命令详解
• 2.1 hset，hget，hexists，hdel
• 2.2 hexists，hdel
• 2.3 hkeys，hvals
• 2.4 hgetall，hmget
• 2.5 hlen，hsetnx
• 2.6 hincrby，incrbyfloat
• 三，hash编码方式
• 3.1 ziplist
• 3.2 hashtable
• 3.3 演示
• 四，应用场景

一，hash基本情况

哈希是我们目前接触到的数据结构中最重要的一个：

日常开发中，出场频率非常高面试中，非常重要的考点

 Redis自身已经是键值对结构了，就是通过哈希的方式来组织的，而hash类型，就是把key这一层组织完之后，到了value这一层，其中的一种类型还可以再是一个哈希表：

哈希类型中的映射关系通常称为 field-value，⽤于区分 Redis 整体的键值对（key-value）， 注意这⾥的 value 是指 field 对应的值，不是键（key）对应的值，请注意 value 在不同上下文的作用。

关于哈希的详细解释以前已经介绍过，传送门：C++&&数据结构——哈希表_c++哈希表

二，hash常用命令详解

2.1 hset，hget，hexists，hdel

hset就是同时建立key-value和field-value键值对，前者是Redis的键值对，后者是value的键值对；hget就是查询键值对：

2.2 hexists，hdel

hexists的作用是判断指定key的field是否存在，存在就返回1，否则返回0；hdel就是删除，删除key的某一个field-value，当key的field数量为0时，会顺带把key一起删了：

2.3 hkeys，hvals

hkeys作用是根据key找到所有的field并打印出来；hvals作用是获取所有的field和value，但不会显示field：

当然，像这样的“查询所有”的这种操作，也会有和keys *一样的问题的，但是也有解决方法，就是hscan遍历Redis的hash类型，属于“渐进式遍历”，我们后面再讲~ 

2.4 hgetall，hmget

hgetall相当于把上面两个命令合起来，同时显示field和value，以两两交替的方式打印出来；hgetall是一次查所有，但是我们有时只要查一部分，所以可以用hmget，就是根据命令行输入field获取对应value，可以一次查多个：

注意：

hgetall同样有keys * 的问题hmget的显示顺序和我们命令行输入的field的顺序是一致的也有hmset一次设置多个field和value，但是不用，因为hset已经可以支持一次设置多个field和value了

2.5 hlen，hsetnx

hlen是获取hash中field-value键值对的个数；hsetnx和前面的setnx一样，如果field不存在就创建，存在就直接返回：

2.6 hincrby，incrbyfloat

hash类型中field的value也可以当作int处理，hincrby可以加减整数，incrbyfloat可以加减小数：

三，hash编码方式

3.1 ziplist

我们经常用到的压缩有rar，zip，7z等，通常是一些具体的压缩算法，本质是针对数据进行重新编码，不同的数据有不同的特定，结合这些特点进行精妙的计算，重新编码过后，就嫩缩小数据的体积：

 ziplist同理，内部的数据结构也是精心设计的，表示一个普通的哈希表，可能会浪费一定的空间（哈希是一个数组，数组上有些位置有元素，有些没有），使用ziplist就可以节省空间，内部的具体实现我们以后再看源码解析

当然，有好处自然会有坏处：读写元素较慢，如果元素较少，慢的并不明显，所以当哈希的元素个数较少，就会用ziplist去优化

当哈希类型元素个数⼩于 hash-max-ziplist-entries 配置（默认 512 个，我们一般会根据业务修改）、 同时所有值都⼩于 hash-max-ziplist-value 配置（默认 64 字节）时，Redis 会使⽤ ziplist 作为哈 希的内部实现，ziplist 使⽤更加紧凑的结构实现多个元素的连续存储，所以在节省内存⽅⾯⽐ hashtable 更加优秀。

3.2 hashtable

只有“元素个数太少”，“长度比较短”两个条件都具备，才会优化成ziplist，当hash类型⽆法满⾜ 这两个条件时，Redis 会使⽤ hashtable 作为哈希 的内部实现，因为此时 ziplist 的读写效率会下降，⽽ hashtable 的读写时间复杂度为 O(1)。

3.3 演示

元素很多时就用hashtable来存 

四，应用场景

最主要的应用场景还是作为缓存来使用，但是hash类型作为缓存有点特别，下面来具体讲讲

string也是可以用作缓存的，但是Redis是经常和mysql打交道的，所以如果要存储MySQL表里面那样的结构化数据，使用hash类型更合适一些：

其实上述场景也可以用strin类型也能做到，需要用到 json 这样的数据格式

• 但是如果使用json的格式来表示上面的user时，如果我只想获取或修改其中的一个field，就需要把整个json都读出来，解析成对象，然后重写对应的field，再写回去，效率变低
• 而使用hash，就可以使用field表示对象的每个舒徐（相当于操作MySQL的每个列），次数就可以非常方便地修改任何一个属性的值了
• 但是使用hash的方式，确实读写field更直观和高效，但是付出的是空间的代价，而且还需要控制hash再ziplist和hashtable两种内部编码的转换，可能会造成较大的内存消耗

到此这篇关于Redis远程字典服务器 hash类型详解的文章就介绍到这了,更多相关Redis hash类型内容请搜索编程网(www.lsjlt.com)以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程客栈(www.lsjlt.com)！