Redis为什么快?

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承受不起,所以它需要对时间进行缓存,由一个定时任务,每毫秒更新一次时间缓存,获取时间都是从缓存中直接拿

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>