redis----第二天学习笔记（数据结构：快速的redis有哪些慢操作？）

redis----第二天学习笔记（数据结构：快速的redis有哪些慢操作？）

提到Redis，相信大家脑子里马上就会联想到它的“快”，但大家有考虑过Redis的快，快在哪里吗？实际上，这里有一个重要的表现：它接收到一个键值对操作后，能以微妙级别的的速度找到数据，并快速完成操作。

数据库的种类有这么多。为什么Redis能有这么突出的表现呢？一方面，这是因为它是内存数据库，所有操作都在内存上完成；内存的访问速度本身就很快。另一方面，这也归功于它的数据结构。这是因为键值对是按一定的数据结构来组织的，操作键值对最终就是对数据结构进行增删改查操作，所以高效的数据结构是Redis快速处理数据的基础。本节课就围绕数据结构进行展开讨论。

像String(字符串)、List(列表)、Hash(哈希)、Set（集合）、Sorted Set（有序集合）像这些只是Redis键值对中值的数据类型，也就是数据的保存形式。而这里，我们说的数据结构，是要去看他们的底层实现。
简单来说，底层数据结构一共有6种，分别是简单动态字符串、双向链表、压缩列表、哈希表、跳表和整数数组。它们和数据类型的对应关系如下图：

可以看到，String类型的底层实现只有一种数据结构，也就是简单动态字符串。而List、Hash、Set和SortSet这四种类型成为集合类型，它们的特点是一个键对应了一个集合的数据。
看到这里，可以讨论出一些问题：

• 这些数据结构都是值的底层实现，键和值之间用什么结构组织？
• 为什么集合类型有那么多的底层结构，它们都是怎么样组织数据的，都很快吗？
• 什么是简单动态字符串，和常用的字符串是一回事？

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

看到这里，有人可能会问：如果值是集合类型的话，作为元素数组的哈希桶怎么来保存呢？其实，哈希桶中的元素保存的并不是值本身，而是指向具体值的指针。这也就是说，不管值是String,还是集合类型，哈希桶中的元素都是指向它们的指针。

在下图中，可以看到哈希桶中的entry元素中保存了key和value指针，分别指向了实际的键和值，这样一来，即使值是一个集合，也可以通过 *value指针被查找到。

因为这个哈希表保存了所有的键值对，所以，我也把它称为全局哈希表。哈希表的最大好处明显，就是让我们可以用O（1）的时间复杂度来快速查找到键值对----我们只需要计算键的哈希值，就可以知道他所对应的哈希桶位置，然后就可以访问相应的entry元素。

可以看出，这个查找过程主要依赖于哈希计算，和数据量的多少并没有直接关系。也就是说，不管哈希表里有10万个键还是100万个键，我们只需要一次计算就能找到相应的键。
但是，如果你只是了解了哈希表的O(1)复杂度和快速查找特性，那么当你往Redis里写入大量数据后，就可能发现操作有时候会变慢了。这其实是因为你忽略了一个潜在的风险点，那就是哈希表的冲突问题和rehash可能带来的操作阻塞。

为什么哈希表操作变慢了？
当你往哈希表中写入更多数据时，哈希冲突是不可避免的问题。这里的哈希冲突也就是指，两个key的哈希值和哈希桶计算对应关系时，正好落入了同一个哈希桶中。
Redis解决哈希冲突的方式，就是链式哈希。链式哈希也很容易理解，就是指同一个哈希桶中的多个元素泳一个链表来保存，他们之间依次用指针连接。

如下图所示：entry1、entry2和entry3都需要保存到哈希桶3中，导致了哈希冲突。此时，entry1元素会通过一个next指针指向entry2，同样，entry2也会通过next指针指向entry3.这样一来，即使哈希桶3中的元素有00个，我们也可以通过entry元素中的指针，把它们连接起来。这就形成了一个链表，也叫做哈希冲突链。

但是这里依然存在一个问题，哈希冲突链上的元素只能通过指针逐一查找在操作。如果哈希表里写入的数据越来越多，这就会导致某些哈希冲突链过长，进而导致这个链上的元素查找耗时长，效率较低，对于追求“快”的Redis来说，是不太能接受的。
所以Redis会对哈希表做rehash操作。rehash也就是增加现有的哈希桶数量，让逐渐增多的entry元素能在更多的桶之间分散保存，减少单个桶中的元素数量，从而减少单个桶中的冲突。那具体怎么做呢？

其实为了使rehash操作更高效，Redis默认使用了两个全局哈希表：哈希表1和哈希表2，一开始，当你刚插入数据时，默认使用哈希表1，此时的哈希表2并没有被分配空间。随着数据逐步增多。Redis开始执行rehash，这个过程分三步：

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

到此我们就可以从哈希表1切换到哈希表2，用增大的哈希表2保存更多数据，而原来的哈希表1留作下一次rehash扩容备用。

这个过程看似简单，但是第二部涉及大量的数据拷贝，如果一次性把哈希表1中的数据都迁移走，会造成redis线程阻塞，无法服务其他请求。此时，Redis就无法快速访问数据了。

为了避免这个问题，Redis采用了渐进式rehash。
简单来说就是在第二步拷贝数据时，Redis仍然正常处理客户端请求，每处理一个请求时，从哈希表1中的第一个索引位置开始，顺带着将这个索引位置上的所有entries拷贝到哈希表2中；等处理下一个请求时，在顺带拷贝哈希表1中的下一个索引位置的entries。如下所示：

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

到这里应该可以理解Redis的键和值是怎么用过哈希表组织的了。对于String来说，找到哈希桶就能直接增删改查，所以哈希表的O（1）复杂度也就是它的复杂度了。
但是，对于集合类型来说，即使找到哈希桶了，还要在集合中在进一步操作。接下来我们来看看集合类型的操作效率是怎么样的。

集合数据操作效率：
和String类型不同，一个集合类型的值，第一步是通过全局哈希表找到对应的哈希桶位置，第二步时在集合中在增删改查。那么集合的操作效率和哪些因素相关呢？

首先，与集合的底层数据结构有关。例如，使用哈希标配实现的集合，要比使用链表实现的集合访问效率更高。其次，操作效率和这些操作本身的执行特点有关，比如读写一个元素对的操作要比读写所有元素的效率高。

下面简单的说一下集合类型的底层数据结构和操作复杂度：

有哪些底层数据结构：

• 集合类型的底层数据结构主要有5种：整数数组、哈希表、双向链表、压缩列表和跳表。
• 其中，哈希表的操作特点我们已经介绍过了；整数数组和双向链表也很常见，他们的操作特征都是顺序读写，也就是通过数组下标或者链表的指针逐个元素访问，操作复杂度基本是o(n）,操作效率比较低；压缩列表和跳表我们平时也接触的可能不多，但他们也是redis重要的数据结构，所以特此强调一下：
  压缩列表实际上类似于一个数组，数组中的每一个元素都对应保存一个数据。和数组不同的是，压缩列表在表头有三个字段zlbytes\zltail\zllen分别表示列表长度、列表尾的偏移量和列表中的entry个数；压缩列表在表尾还有个zlend，表示列表结束。

在压缩列表中，如果我们要查找定位第一个元素和最后一个元素，可以通过表头三个字段的长度直接定位，复杂度是O(1).而查找其他元素的时候，就没有这么高效了，只能逐个查找，此时的复杂度就是O(N)了。

再继续了解下跳表，有序链表只能逐一查找元素，导致操作起来非常慢，于是就出现了跳表。具体来说，跳表在链表的基础上，增加了多级索引，通过索引位置的几个跳转，实现数据的快速定位。如下所示：

如果我们要在链表中查找33这个元素，只能从头开始遍历链表，查找6次，直到找到33为止。此时，复杂度是O（N），查找效率很低。
为了提高查找速度，我们采用增加一级索引来提高效率，从第一个元素开始，每2个元素选一个出来作为索引。这些索引在通过指针指向原始的链表，例如：从前两个元素中抽取元素11作为一级索引。此时我们只需要4次查找就可以定位到元素33了

如果我们还想更快，可以再增加二级索引；从一级索引中，在抽取部分元素作为二级索引。例如：从一级索引中抽取1、27、100作为二级索引，二级索引指向一级索引。这样，我们就只需要三次查找就可以定位到元素33了。

可以看到，这个查找过程就是字多级索引上跳来跳去，最后定位到元素。这也正好符合“跳”表的说法，当数据量很大的时候，跳表的复杂度就是O（logN）。

根据上述，我们可以按照查找的时间复杂度给这些数据结构分一下类：

不同的操作的复杂度：
集合类的操作类型有很多，有读写单个集合元素的，例如HGET/HSET也有操作多个元素的，例如SADD，还有对整个集合进行遍历操作的；例如SMEMBERS。这么多操作，他们的复杂度也有不同。而复杂度的高低又是我们选择类型的重要依据，

有老师总结了一个很经典的“四句口诀”：

• 单元素操作是基础
• 范围操作非常好使
• 统计操作通常高效
• 例外情况只有几个

第一，单元素操作，是指每一种集合类型对单个数据实现增删改查操作。例如Hash类型的HGET、HSET和HDEL，Set类型的SADD、SREM、SRANDMEMBER等。这些操作的复杂度由集合采用的数据机构决定，例如，HGET、HSET和HDEL是对哈希表做操作，所以它们的复杂度都是O（1），Set类型用哈希表作为底层数据结构时，它的SADD、SREM、SRANDMEMBER复杂度也是O（1）。

这里有个地方需要注意一下，集合类型支持同时对多个元素进行增删改查操作，例如Hash类型的HMGET和HMSET。Set类型的SADD也支持同时增加多个元素。此时，这些操作的复杂度，就是由单个元素操作复杂度个元素个数决定的。例如。HMSET增加M个元素时，复杂度就从O(1)变成O(M)了。

第二，范围操作，是指集合类型中的便利操作，可以返回集合中的所有数据，比如Hash类型的HGETALL和SET类型的SMEMBERS，或者返回一个范围内的部分数据，比如List类型的LRANGE和ZSET类型的ZRANGE，这类操作的复杂度一般是O（N），比较耗时，我们应该尽量避免。

不过Redis从2.8版本开始提供了SCAN操作（包括HSCAN,SSCAN,ZSCAN）这类操作实现了渐进式遍历，每次返回有限数量的数据，这样一来，相比于HGETALL,SMEMBERS这类操作来说，就避免了一次性返回所有元素而导致的redis阻塞。

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

第四，例外情况，是指某些数据结构的特殊记录，例如压缩列表和双向链表都会记录表头和表尾的偏移量，这样一来，对于list类型的LPOP、RPOP、LPUSH、RPUSH这四个操作来说，它们是在列表的头尾删除元素，这就是可以通过偏移量直接定位，所以它们的操作复杂度也只有O(1)，可以实现快速操作。

小结
本次主要学习了Redis的底层数据结构，这即包括了redis中用来保存每个键和值的全局哈希表结构，也包括了支持集合类型实现的双向链表、压缩列表、整数数组、哈希表和跳表这五大底层结构。

Redis之所以能快速操作键值对，一方面是因为O(1)复杂度的哈希表被广泛使用，包括String、Hash和Set,它们的操作复杂度基本由哈希表决定，另一方面，Sorted Set也采用了O(logN)复杂度的跳表。不过。集合类型的范围操作，因为要遍历底层数据结构，复杂度通常是O(N)。因此，我觉得要因地制宜的使用List类型。例如：既然它们的POP/PYSH效率很高，那么就将它主要用于FIFO队列场景，而不是作为一个可以随机读写的集合。
使用redis我们通常无法一下子记住所有的操作的复杂值，它的类型丰富，每个类型的操作也很多。所以最好的办法就是掌握原理，只要掌握了数据结构原理，就可以从原理上推断不同操作的复杂度。