移动版网站建设/网络推广费用

Redis为什么快？

• 纯内存访问；

• 单线程避免上下文切换；

• 渐进式ReHash、缓存时间戳；

前面两个都比较好理解，下面我们主要来说下 渐进式ReHash 和 缓存时间戳。

渐进式ReHash

全局哈希表

为了实现从键到值的快速访问，Redis使用了一个哈希表来保存所有的键值对。一个哈希表，其实就是一个数组，数组的每个元素称为一个哈希桶。所以，我们常说，一个哈希表是由多个哈希桶组成的，每个哈希桶中保存了键值对数据。

哈希桶中的 entry 元素中保存了 key 和 value 指针，分别指向了实际的键和值，这样一来，即使值是一个集合，也可通过 *value 指针被查找到。因为这个哈希表保存了所有的键值对，所以，我也把它称为全局哈希表。

哈希表最大的好处很明显，就是让我们可以用O(1)的时间复杂度来快速查找到键值对，我们需要计算键值的哈希值，就可以知道它所对应的哈希桶的位置，然后就可以访问相应的 entry 元素。

但当你往 Redis 中写入大量数据后，就可能发现操作有时候会突然变慢了，这其实是因为你忽略了一个潜在的风险点，那就是 哈希表的冲突问题 和 ReHash可能带来的操作阻塞。

当你往哈希表中写入更多数据时，哈希冲突时不可避免的问题。这里的哈希冲突，两个 key 的哈希值和哈希桶计算对应关系时，正好落在同一个哈希桶中。

Redis解决哈希冲突的方式，就是链式哈希，链式哈希也很容易理解，就是指同一个哈希桶中的多个元素用一个链表来保存，它们之间依次用指针连接。

当然如果这个数组一直不变，那么hash冲突会变很多，这个时候检索效率会大打折扣，所以Redis就需要把数组进行扩容（一般是扩大到原来的两倍），但是问题来了，扩容后每个hash桶的数据会分散到不同的位置，这里设计到元素的移动，必定会阻塞IO，所以这个ReHash过程会导致很多请求阻塞。

渐进式ReHash

为了避免这个问题，Redis 采用了渐进式 ReHash。

首先，Redis 默认使用了两个全局哈希表：哈希表1 和 哈希表2。一开始，当你刚插入数据时，默认使用哈希表1，此时的哈希表2并没有被分配空间。随着数据逐步增多，Redis开始执行 ReHash。

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

在上面的第二步涉及大量的数据拷贝，如果一次性把哈希表1中的数据都迁移完，会造成Redis线程阻塞，无法服务其他请求，此时，Redis就无法快速访问数据了。

在Redis开始执行 ReHash，Redis仍然正常处理客户端请求，但是要加入一个额外的处理：

• 处理第一个请求时，把哈希表1中的第一个索引位置上的所有 entries 拷贝到哈希表2中；

• 处理第二个请求时，把哈希表1中的第二个索引位置上的所有 entries 拷贝到哈希表2中；

• 如此循环，直到把所有的索引位置的数据都拷贝到哈希表2中。

这样就巧妙的把一次性大量拷贝的开销，分摊到了多次处理请求的过程中，避免了耗时操作，保证了数据的快速访问。

所以这里基本上也可以确保根据 key 找 value 的操作在O(1) 左右。

不过这里要注意，如果Redis中有海量的 key 值的话，这个ReHash过程会很长很长，虽然采用渐进式ReHash，但在ReHash的过程中还是会导致请求有不小的卡顿，并且像一些统计命令也会非常卡顿，比如keys按照Redis的配置每个实例能存储的最大的key的数量为2的32次方，即2.5亿，但是尽量把key的数量控制在千万以下，这样就可以避免ReHash导致的卡顿问题，如果数量确实比较多，建议采用分区hash存储。

缓存时间戳

我们平时使用系统时间戳时，常常是不假思索的使用 System.currentTimeInMillis 或者 time.time() 来获取系统的毫秒时间戳。Redis不能这样，因为每一次获取系统时间戳都是一次系统调用，系统调用相对来说是比较费时间的，作为单线程的Redis承受不起，所以它需要对时间进行缓存，由一个定时任务，每毫秒更新一次时间缓存，获取时间都是从缓存中直接拿。