Redis的hash是什么

重点

Redis的hash是一种键值对集合，可以将多个字段和值存储在同一个键中。

• 适合存储小数据，用哈希表实现，能够在内存中高效存储和操作
• 支持快速的字段操作（crud），适合存储对象的属性

底层实现

• Redis6及以前，hash的底层是压缩列表加哈希表的数据结构
• Redis7及以后，hash的底层是紧凑列表加哈希表的数据结构

为什么不直接用哈希表，而是先使用紧凑列表和压缩列表

• 内存占用方面：压缩列表和紧凑列表都是紧凑的内存结构，他们没有像哈希表那样存在额外的指针开销。哈希表为了维持快速查找特性，内部采用链表法解决
  哈希冲突，每个哈希桶都会带有指针，这使得内存占用开销较大。另外两个数据结构主要通过将数据存储在一块的连续内存（CPU缓存友好），从而使内存占用最小。
• 性能方面： 哈希表的访问速率是O(1)，但那是没有涉及链表操作的情况下，因为我们知道Hash解决哈希冲突是通过链地址法结局的，链表的遍历由于是
  在内存中为散落的形式，不像其他两个是连续数组存储，所以性能不一定比压缩列表和紧凑列表快。

压缩列表和紧凑列表查找key的效率是类似的，时间复杂度都是O(n),主要区别在于紧凑列表解决了压缩列表的级联更新问题

级联更新

• 压缩列表记录每个元素的前一个元素的长度，当某元素长度从小变大时会从1字节扩展到5字节，导致后续元素的前驱长度连锁扩展。
• 紧凑列表不存储前驱长度，而是在每个元素末尾写入自身的“回退长度”（仅影响当前元素）。

什么时候会向哈希表升级？

Redis内有两个值：hash-max-ziplist-entries和hash-max-ziplist-value。 即哈希类型键的字段个数（默认512）以及每个字段的长度（默认64）

当hash小于这两个值的时候，会使用压缩列表或紧凑列表。

但是：在升级为哈希表后，就不会在退化为压缩列表或紧凑列表