End

数据结构与算法-7 Redis 中的数据类型

本文地址

目录

目录

实战篇介绍

到此为止，专栏前三部分我们全部讲完了。从今天开始，我们就正式进入实战篇的部分。这部分我主要通过一些开源项目、经典系统，真枪实弹地教你，如何将数据结构和算法应用到项目中。所以这部分的内容，更多的是知识点的回顾，相对于基础篇、高级篇的内容，其实这部分会更加容易看懂。

不过，我希望你不要只是看懂就完了。你要多举一反三地思考，自己接触过的开源项目、基础框架、中间件中，都用过哪些数据结构和算法。你也可以想一想，在自己做的项目中，有哪些可以用学过的数据结构和算法进一步优化。这样的学习效果才会更好。

52 | Redis 中数据类型对应的数据结构

经典数据库 Redis 中的常用数据类型，底层都是用哪种数据结构实现的呢？

Redis 数据库介绍

Redis 是一种键值数据库。相对于关系型数据库（比如 MySQL），Redis 也被叫作非关系型数据库。

像 MySQL 这样的关系型数据库，表的结构比较复杂，会包含很多字段，可以通过 SQL 语句来实现非常复杂的查询需求。而 Redis 中只包含“键”和“值”两部分，只能通过“键”来查询“值”。正是因为这样简单的存储结构，也让 Redis 的读写效率非常高。

除此之外，Redis 主要是作为内存数据库来使用，也就是说，数据是存储在内存中的(它也支持将数据存储在硬盘中)。

Redis 中，键的数据类型是字符串，值的数据类型有很多，常用的数据类型有

  • 字符串
  • 列表
  • 字典
  • 集合
  • 有序集合

我们看下，它们底层都依赖了哪些数据结构。

列表 list

列表这种数据类型支持存储一组数据。这种数据类型对应两种实现方法，一种是压缩列表，另一种是双向循环链表。

压缩列表

当列表中存储的数据量比较小的时候，列表就可以采用压缩列表(ziplist)的方式实现。具体需要同时满足下面两个条件：

  • 列表中保存的单个数据大小要小于 64 字节
  • 列表中数据个数要少于 512 个

压缩列表并不是基础数据结构，而是 Redis 自己设计的一种数据存储结构。它有点儿类似数组，通过一片连续的内存空间来存储数据。不过，它跟数组不同的一点是，它允许存储的数据大小不同。

压缩列表不支持随机访问。但是因为 Redis 一般都是通过 key 获取整个 value 的值，也就是获取整个压缩列表的数据，因此压缩列表并不需要支持随机访问。

另外，作为内存数据库，相比节省时间，Redis 更倾向于节省空间(时间换空间)。

具体的存储结构也非常简单，你可以看我下面画的这幅图。

之所以说这种存储结构节省内存，是相较于数组的存储思路而言的。我们知道，数组要求每个元素的大小相同，如果我们要存储不同长度的字符串，那我们就需要用最大长度的字符串大小，作为元素的大小，这样便会浪费部分存储空间。

关于上面说的"数组要求每个元素的大小相同"这一点，我有疑问
1、在 Java 中，存储基础类型(int、char)数据的数组，这一点当然是成立的
2、但是对于存储引用类型(String、对象)数据的数组，应该没有这个要求，因为数组中存的并不是对象本身，而是对象的指针，对象本身的大小可以各不相同
3、因此，也就不存在所谓的"浪费部分存储空间"的问题
4、然而，由于 Redis 是用 c 实现的，所以上面给出的应该是针对 c 环境的分析

压缩列表这种存储结构，一方面比较节省内存，另一方面可以支持不同类型数据的存储。

双向循环链表

当列表中存储的数据量比较大的时候，也就是不能同时满足刚刚讲的两个条件的时候，列表就要通过双向循环链表来实现了。

Redis 的这种双向链表的实现方式，非常值得借鉴。它额外定义一个 list 结构体，来组织链表的首、尾指针，还有长度等信息。这样，在使用的时候就会非常方便。

以下是C语言代码，因为Redis是用C语言实现的

typedef struct listnode {
  struct listNode *prev;
  struct listNode *next;
  void *value;
} listNode;

typedef struct list {
  listNode *head; //头指针
  listNode *tail; //尾指针
  unsigned long len; //长度
  // ...
} list;

字典 hash

字典类型用来存储一组数据对，每个数据对又包含键值两部分。

字典类型也有两种实现方式，一种是我们刚刚讲到的压缩列表，另一种是散列表。

压缩列表

同样，只有当存储的数据量比较小的情况下，Redis 才使用压缩列表来实现字典类型。具体需要满足两个条件：

  • 字典中保存的键和值的大小都要小于 64 字节
  • 字典中键值对的个数要小于 512 个

散列表

当不能同时满足上面两个条件的时候，Redis 就使用散列表来实现字典类型。

  • Redis 使用 MurmurHash2 这种运行速度快、随机性好的哈希算法作为哈希函数
  • Redis 使用链表法来解决于哈希冲突问题
  • Redis 还支持散列表的动态扩容、缩容

当数据动态增加之后，散列表的装载因子会不停地变大。为了避免散列表性能的下降，当装载因子大于 1 的时候，Redis 会触发扩容，将散列表扩大为原来大小的 2 倍左右（具体值需要计算才能得到）。

当数据动态减少之后，为了节省内存，当装载因子小于 0.1 的时候，Redis 就会触发缩容，缩小为字典中数据个数的大约 2 倍大小（这个值也是计算得到的）。

为了解决扩容缩容要做大量的数据搬移，和哈希值的重新计算，导致的耗时问题，Redis 使用渐进式扩容缩容策略，将数据的搬移分批进行，避免了大量数据一次性搬移导致的服务停顿。

集合 set

集合这种数据类型用来存储一组不重复的数据。这种数据类型也有两种实现方法，一种是基于有序数组，另一种是基于散列表。

有序数组

当要存储的数据，同时满足下面这样两个条件的时候，Redis 就采用有序数组，来实现集合这种数据类型。

  • 存储的数据都是整数
  • 存储的数据元素个数不超过 512 个

散列表

当不能同时满足这两个条件的时候，Redis 就使用散列表来存储集合中的数据。

有序集合 sortedset

跳表

有序集合这种数据类型，我们在跳表里已经详细讲过了。它用来存储一组数据，并且每个数据会附带一个得分。通过得分的大小，我们将数据组织成跳表这样的数据结构，以支持快速地按照得分值、得分区间获取数据。

压缩列表

实际上，跟 Redis 的其他数据类型一样，有序集合也并不仅仅只有跳表这一种实现方式。当数据量比较小的时候，Redis 会用压缩列表来实现有序集合。具体点说就是，使用压缩列表来实现有序集合的前提，有这样两个：

  • 所有数据的大小都要小于 64 字节
  • 元素个数要小于 128 个

数据结构持久化

尽管 Redis 经常会被用作内存数据库，但是，它也支持数据落盘，也就是将内存中的数据存储到硬盘中。这样，当机器断电的时候，存储在 Redis 中的数据也不会丢失。在机器重新启动之后，Redis 只需要再将存储在硬盘中的数据，重新读取到内存，就可以继续工作了。

刚刚我们讲到，Redis 的数据格式由“键”和“值”两部分组成。而“值”又支持很多数据类型，比如字符串、列表、字典、集合、有序集合。像字典、集合等类型，底层用到了散列表，散列表中有指针的概念，而指针指向的是内存中的存储地址。 那 Redis 是如何将这样一个跟具体内存地址有关的数据结构存储到磁盘中的呢？

实际上，Redis 遇到的这个问题并不特殊，很多场景中都会遇到。我们把它叫作数据结构的持久化问题，或者对象的持久化问题。这里的“持久化”，你可以笼统地理解为“存储到磁盘”。

如何将数据结构持久化到硬盘？我们主要有两种解决思路。

第一种是清除原有的存储结构，只将数据存储到磁盘中。当我们需要从磁盘还原数据到内存的时候，再重新将数据组织成原来的数据结构。实际上，Redis 采用的就是这种持久化思路。

不过，这种方式也有一定的弊端。那就是数据从硬盘还原到内存的过程，会耗用比较多的时间。比如，我们现在要将散列表中的数据存储到磁盘。当我们从磁盘中，取出数据重新构建散列表的时候，需要重新计算每个数据的哈希值。如果磁盘中存储的是几 GB 的数据，那重构数据结构的耗时就不可忽视了。

第二种方式是保留原来的存储格式，将数据按照原有的格式存储在磁盘中。我们拿散列表这样的数据结构来举例。我们可以将散列表的大小、每个数据被散列到的槽的编号等信息，都保存在磁盘中。有了这些信息，我们从磁盘中将数据还原到内存中的时候，就可以避免重新计算哈希值。

课后思考

在数据量大小不同的场景中，Redis 中的很多数据类型，比如字典、有序集合等，都是通过多种数据结构来实现的，为什么会这样设计呢？用一种固定的数据结构来实现，不是更加简单吗？

参考答案：
较小数据的时候使用压缩列表，可减小内存占用，小内存对cpu友好，有利于使用I2缓存
较大数据的时候使用散列表，方便随机查找，压缩列表不能随机查找，较大数据时效率低

2017-10-15

posted @ 2017-10-15 16:58  白乾涛  阅读(1337)  评论(0)  编辑  收藏  举报