目录
一，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++哈希表-CSDN博客
二，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两种内部编码的转换，可能会造成较大的内存消耗
