数据结构：快速的 Redis 有哪些慢操作
- 数据库这么多，为啥 Redis 能有这么突出的表现呢？
- 一方面，因为它是内存数据库，所有操作都在内存上完成，内存的访问速度本身就很快。
- 另一方面，因为，键值对是按一定的数据结构来组织的，操作键值对最终就是对数据结构进行增删改查操作，所以高效的数据结构是 Redis 快速处理数据的基础。
- 简单来说，底层数据结构一共有 6 种，分别是简单动态字符串、双向链表、压缩列表、哈希表、跳表和整数数组。
键和值用什么结构组织？
- 为了实现从键到值的快速访问，Redis 使用了一个哈希表来保存所有键值对。
- 一个哈希表，其实就是一个数组，数组的每个元素称为一个哈希桶。
- 一个哈希表是由多个哈希桶组成的，每个哈希桶中保存了键值对数据。
- **哈希桶中的元素保存的并不是值本身，而是指向具体值的指针。**这也就是说，不管值是 String，还是集合类型，哈希桶中的元素都是指向它们的指针。
- 哈希桶中的 entry 元素中保存了 *key 和 *value 指针，分别指向了实际的键和值，这样一来，即使值是一个集合，也可以通过 *value 指针被查找到。
- 因为这个哈希表保存了所有的键值对，所以，我也把它称为全局哈希表。
- 哈希表的最大好处很明显，就是让我们可以用 O(1) 的时间复杂度来快速查找到键值对⸺我们只需要计算键的哈希值，就可以知道它所对应的哈希桶位置，然后就可以访问相应的 entry 元素。
为什么哈希表操作变慢了？
- 当你往哈希表中写入更多数据时，哈希冲突是不可避免的问题。
- 哈希冲突就是指两个 key 的哈希值和哈希桶计算对应关系时，正好落在了同一个哈希桶中。
- Redis 解决哈希冲突的方式，就是链式哈希，即同一个哈希桶中的多个元素用一个链表来保存，它们之间依次用指针连接。
- 哈希冲突链上的元素只能通过指针逐一查找再操作。
- 如果哈希表里写入的数据越来越多，哈希冲突可能也会越来越多，这就会导致某些哈希冲突链过长，进而导致这个链上的元素查找耗时长，效率降低。
- 对于追求“快”的 Redis 来说，这是不太能接受的。
- 所以，Redis 会对哈希表做 rehash 操作。
- rehash 也就是增加现有的哈希桶数量，让逐渐增多的 entry 元素能在更多的桶之间分散保存，减少单个桶中的元素数量，从而减少单个桶中的冲突。
- 其实，为了使 rehash 操作更高效，Redis 默认使用了两个全局哈希表：哈希表 1 和哈希表 2。
- 一开始插入数据时，默认使用哈希表 1，此时的哈希表 2 并没有被分配空间。
- 随着数据逐步增多，Redis开始执行 rehash，这个过程分为三步：、
- 给哈希表 2 分配更大的空间，例如是当前哈希表 1 大小的两倍；
- 把哈希表 1 中的数据重新映射并拷贝到哈希表 2 中；
- Redis 采用了渐进式 rehash。
- 每处理一个请求时，从哈希表 1 中的第一个索引位置开始，顺带着将这个索引位置上的所有 entries 拷贝到哈希表 2 中；
- 等处理下一个请求时，再顺带拷贝哈希表 1 中的下一个索引位置的 entries。
- 释放哈希表 1 的空间。
集合数据操作效率
- 和 String 类型不同，一个集合类型的值，第一步是通过全局哈希表找到对应的哈希桶位置，第二步是在集合中再增删改查。
- 集合类型的底层数据结构主要有 5 种：整数数组、双向链表、哈希表、压缩列表和跳表。
- 压缩列表实际上类似于一个数组，数组中的每一个元素都对应保存一个数据。
- 和数组不同的是，压缩列表在表头有三个字段 zlbytes、zltail 和 zllen，分别表示列表长度、列表尾的偏移量和列表中的 entry 个数；
- 压缩列表在表尾还有一个 zlend，表示列表结束。
- 在压缩列表中，如果我们要查找定位第一个元素和最后一个元素，可以通过表头三个字段的长度直接定位，复杂度是 O(1)。
- 查找其他元素时，就只能逐个查找，此时的复杂度就是 O(N)。
- 跳表在链表的基础上，增加了多级索引，通过索引位置的几个跳转，实现数据的快速定位。
- 为了提高查找速度，我们来增加一级索引：从第一个元素开始，每两个元素选一个出来作为索引。这些索引再通过指针指向原始的链表。
- 如果我们还想再快，可以再增加二级索引：从一级索引中，再抽取部分元素作为二级索引。
- 可以看到，这个查找过程就是在多级索引上跳来跳去，最后定位到元素。
- 当数据量很大时，跳表的查找复杂度就是 O(logN)。
- 压缩列表实际上类似于一个数组，数组中的每一个元素都对应保存一个数据。
