Redis速度之谜：揭秘其高效性能

• 读写完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。
• 采用单线程读写，避免了不必要的上下文切换和锁竞争条件，避免额外消耗 CPU
• 采用高性能的IO多路复用模型
• 底层高效的数据结构(简单的动态字符串/双端链表/压缩链表/哈希表/跳跃表等等)，提升查找以及存储的效率
• 采取渐进式的Rehash

渐进式rehash

在Redis中，如果哈希表的数组一直保持不变，就会增加哈希冲突的可能性，从而降低检索效率。为了解决这个问题，Redis会对数组进行扩容，通常是将数组大小扩大为原来的两倍。然而，这个扩容过程会引起元素在哈希桶中的分散，导致元素的移动。由于元素移动会涉及IO操作，所以这个重新哈希（ReHash）过程可能会导致许多请求被阻塞。为了避免这个问题，Redis 采用了渐进式 rehash。

在Redis中，默认使用两个全局哈希表：哈希表1和哈希表2。最初，当你开始插入数据时，只使用哈希表1，而哈希表2没有分配空间。随着数据逐渐增多，Redis开始执行渐进式rehash的过程。

1、为哈希表2分配更大的空间，例如是当前哈希表1大小的两倍。

2、将哈希表1中的数据重新映射并拷贝到哈希表2中，确保每个元素都被正确地存储在新的哈希桶位置上。

3、释放哈希表1的空间，将其回收以便于系统的正常运行。

在上述的第二步中，涉及到大量的数据迁移和拷贝操作。如果一次性将哈希表1中的所有数据都迁移到哈希表2，将导致Redis线程被阻塞，无法提供对其他请求的服务。这将导致Redis无法快速地访问数据。

在Redis开始执行rehash时，Redis仍然可以正常处理客户端请求。然而，在处理每个请求时，Redis还会额外执行以下操作：

• 处理第一个请求时，将哈希表1中第一个索引位置上的所有条目拷贝到哈希表2中。
• 处理第二个请求时，将哈希表1中第二个索引位置上的所有条目拷贝到哈希表2中。
• 如此循环，直到将所有索引位置上的数据都成功拷贝到哈希表2中。

通过将大量数据拷贝的操作分摊到处理请求的过程中，Redis巧妙地避免了一次性的大量数据拷贝开销，从而保证了数据的快速访问。这种处理方式确保了根据键寻找值的操作大致在O(1)的时间复杂度范围内进行。通过渐进式rehash和分步式数据迁移，Redis能够在维持性能的同时，实现平滑的哈希表扩容和数据迁移。