Redis数据结构

Redis数据结构

Redis底层数据结构

Redis底层数据结构一共有6种：简单动态字符串、双向链表、压缩列表、哈希表、跳表、整型数据

除了String类型以外，List、Hash、Sorted Set、Set这四种集合类型，底层都有两种实现结构

键和值的结构组织

Redis使用哈希表保存所有键值对，称为全局哈希表

哈希表是一个数组，数组的每一个元素称为哈希桶，哈希桶中元素保存的是指向具体值的指针，如图所示，哈希桶中的entry元素保存了*key指针和*value指针，分别指向了实际的键和值

哈希冲突

在Redis中写入大量数据后，查询操作可能会变慢，因为可能产生了哈希表冲突问题，rehash操作可能带来了操作阻塞

Redis解决哈希冲突的方式，通过链式哈希解决，只同一个哈希桶中的多个hash冲突的元素用链表保存，它们之间依次用指针连接。

当同一个哈希冲突链上的元素较多，哈希链较长时，该哈希链上的元素只能通过指针逐一查找在操作，最坏情况哈希查找时间复杂度为$O(n)$，效率降低

Redis为防止哈希链过长的情况，会对哈希表做rehash操作，rehash操作即增加现有的哈希桶数量，让entry元素能在更多的哈希桶之间分散保存，减少单个桶中的元素数量，减少单个桶中的冲突

Rehash操作、渐进式Rehash

Redis默认使用两个全局哈希表：哈希表1和哈希表2。一开始插入数据时，只使用哈希表1，哈希表2并不会分配空间（懒！），当数据逐步增多时，Redis开始执行rehash

1. 哈希表2分配更大的空间，例如分配哈希表1的两倍空间
2. 哈希表1的数据重新映射并拷贝到哈希表2中
3. 释放哈希表1的空间

到此，从哈希表1切换到哈希表2，完成扩容，哈希表1留作下一次rehash扩容备用

但是，该过程涉及大量的数据拷贝，如果一次性完成数据拷贝迁移，会造成Redis线程阻塞，无法服务其他请求，无法满足快速访问数据

采用渐进式Rehash避免这个问题

在第二部拷贝数据时，Redis仍然正常处理客户端请求，每处理一个请求时，从哈希表1的第一个索引位置开始，将这个索引位置上的所有entries拷贝到哈希表2中，等待下一个请求，从哈希表1中拷贝下一个索引位置的entries

渐进式Rehash将拷贝的开销分摊到了多次请求处理的过程中，避免了耗时操作，保证了数据快速请求访问

集合数据操作

集合数据操作与其底层数据结构有关

压缩列表

压缩列表与数组类似，与数组的区别是压缩链表表头的三个字段：zlbytes表示列表长度；zltail表示列表尾偏移量；zllen表示列表中entry的个数；压缩列表的表尾还有一个zlend，表示列表结束

压缩列表找第一个元素和最后一个元素都能直接定位，复杂度是$O(1)$，查找其他元素复杂度为$O(N)$

跳表

跳表实在有序链表的基础上，增加了多级索引，通过索引位置的几个跳转，实现数据的快速定位，多级索引的跳表时间复杂度为$O(logN)$

不同操作的复杂度

Redis底层数据结构与对应时间复杂度

1. 单元素操作，复杂度与底层数据结构有关

2. 范围操作，集合类型中的遍历操作，返回集合中的所有数据，例如HGETALL、SEMEBERS、LRANGE、ZRANGE，复杂度为$O(N)$，比较耗时，应该尽量避免
   不过，Redis 从 2.8 版本开始提供了 SCAN 系列操作（包括 HSCAN，SSCAN 和 ZSCAN），这类操作实现了渐进式遍历，每次只返回有限数量的数据。这样一来，相比于 HGETALL、SMEMBERS 这类操作来说，就避免了一次性返回所有元素而导致的 Redis 阻塞。

3. 统计操作，集合类型对集合中所有元素个数的记录，例如LLEN和SCARD。复杂度为$O(1)$，因为集合类型采用压缩列表、双向链表、整数数组这些数据结构时，这些结构中专门记录了元素的个数统计，因此可以高效的完成相关操作

4. 例外情况，数据结构的特殊记录，例如压缩列表和双向链表都会记录表头和表尾的偏移量。List类型的LPOP、RPOP、LPUSH、RPUSH在列表的头尾增删元素，可以通过偏移量直接定位，复杂度为$O(1)$