Redis 全景图（1）--- 关于 Redis 的6大模块

这是我第一次尝试以长文的形式写一篇 Redis 的总结文章。这篇文章我想写很久了，只是一直碍于我对 Redis 的掌握没有那么的好，因此迟迟未动笔。这几天，我一直在看各种不同类型的 Redis 文章，通过阅读这些文章，引发了我对于 Redis 这个大知识点的很多思考。我看过的一篇又一篇的文章都帮助着将我脑子里我学过的 Redis 的零散知识点整合在一起，从而构建一个 Redis 全局系统观，帮助着我用一个全局的方式看待 Redis 这个存储系统。接下来，我计划用文字的方式，将我脑子里的 Redis 蓝图一一描绘出来。

Redis？什么是 Redis？Redis 就是一个键值对数据库。所以，当别人跟你说 Redis 的时候，你的脑子里应该立马想到键值对数据库。我一开始以为这就是 Redis，其实这并不是，这仅仅是 Redis 的其中一个模块而已。对于一个完整的 Redis，应该是由6大模块组成的：访问模块、索引模块、操作模块、存储模块、高可用集群模块、高可扩展集群模块。

访问模块

访问模块就是我们平时一定会接触的 Redis 的网络IO线程模型，如图：

Redis 是一个典型的 client-server 模型。首先，客户端先找 server-socket 建立连接，产生一个事件。IO多路复用器看到这么一个事件就把事件压入队列。文件事件分派器看到队列里有事件就把事件拿出来交给对应的事件处理器进行处理。处理过程是事件处理器会建立一个与客户端 socket 对应的新 socket。只要客户端 socket 与这个新 socket 通信，比如说发起了一个请求，新 socket 就会产生一个事件，然后IO多路复用器就会看到这个事件......重复上面的步骤。

这就是 Redis 的访问模块。访问模块也就是我们说的网络IO单线程模型。我的理解就是如果我们想访问 Redis 里面的键值对数据库，底层第一步要做的就是先进入这个键值对数据库，进入的方式就是我上面说的网络IO单线程模型。

索引模块

OK！回到刚才，我刚刚不是说了通过访问模块，我们已经访问到了键值对数据库了吗？那你有没有想过，这个键值对数据库是长什么样子的，又或者说这些键值对在 Redis 中是怎么存放的，那个画面你想过吗？其实是用一张全局哈希表来存放所有键值对的。这个哈希表由多个哈希桶组成，每个哈希桶存放一个或多个键值对。key 很好理解，因为 key 存放的只是 String 类型，但是 value 就不好理解了，value 支持很多种数据类型（String、列表、哈希、set、zset）。这些数据类型中，除了 String 类型之外，其他的几种类型都是数据集合。不过我当时在学习的时候就想象不出这个画面，我就想，一个 value 能存这么多数据？在我的理解里，我只能理解 value 是 String 类型的这种情况（value 是 String 类型的话，value 是存一个数据的，这很符合我的印象）。后来，我看到了一篇文章，然后我恍然大悟，原来 key-value 键值对存放的并不是实际的值，而是指针，这些指针指向数据集合！就像这样：

如果键值对越来越多，越来越多的话，我们就采用 rehash，即哈希扩容。这里的哈希扩容是渐进式的，没错，就是你学过的那个渐进式哈希扩容，每次对哈希表进行一次插入或者删除操作，就转移一个桶的数据到新表中，就像这样：

操作模块

OK！通过上面的文字和图片，我们应该大致知道 Redis 这个键值对数据库里面大概长什么样了，接下来我们来看看操作模块。操作模块其实就是对键值对的一些操作，除了一些最基础的 put、get、delete 之外，根据 value 中数据类型的不同，会有不同的操作方法。比如说，假如这个键值对的 value 的数据类型是列表 List，那么针对这种数据类型就提供 push 进队和 pop 出队这些对应的操作，就这么简单。

存储模块

这是 Redis 中最核心的模块了，因为这里知识点最多，但是又不是最难，我花了好多时间去理解这个知识点，理解了之后，感觉有种高山看海，海浪真美的感觉。

存储模块，研究的就是 value 中的5种数据类型和底层的6种数据结构，就像这个图：

String ——（动态字符串）

String 这种数据类型真的是万金油，名字虽然叫 String，但是它还可以存文本，数据.....感觉啥都能存。String 类型的底层数据结构是动态字符串，动态字符串提供了丰富的 String 操作命令：增减、排序、查找、计数.....比如我之前实习的公司，它就用 String 来做计数器，用来记录用户的刷新次数，防止一个用户一直刷新。

List ——（双向链表、压缩链表）

List这种数据类型的底层是双向链表的话，我们其实可以用 Redis 来做一个轻量的消息队列，具体怎么实现，我之前好像写过一篇文章：能否把 Redis 当做消息队列来用呢？-CSDN博客

而如果 List 的底层用压缩列表来实现的话，就体现出 Redis 很快很省。因为压缩列表，压缩嘛，肯定省，而且数据被压缩成连续的，所以查找起来就很快。

Hash ——（压缩列表、哈希表）

Hash 这种数据类型的底层实现可以是压缩列表或者是哈希表。如果底层实现是哈希表的话，那么 Redis 就可以用于缓存，比如说缓存用户的基本信息。怎么缓存用户的基本信息？就是 key 是用户ID，value 是用户的基本信息。

Set ——（哈希表、整数数组）

Set 这种数据类型的特点就是无序且不重复。之所有有这种特点，就是因为它底层的数据结构。哈希表是散列的是吧，散列那肯定就无序啊，而哈希表我们都学过不允许存重复的元素，所以数据就不重复。即哈希表是无序不重复的，因此Set也是无序不重复的。如果你用 Redis 来做消息队列的话，那么这个 Set 可以帮助保持消息队列的幂等性（即消息不被重复消费）。假如你理解不了这个例子，那换一个更加简单的，你肯定可以理解的例子。有一个数组a[5]=[2,4,2,4,7,6]，你用一下Set，直接变成了[2,4,7,6],这你能理解了吧！

ZSet —— （压缩列表、跳跃表）

ZSet 和 Set 很像，只不过比起 Set，ZSet 是有序的，就这点不同，其他的感觉大差不差。比如说a[5]=[2,4,2,4,7,6]，你用一下 ZSet，直接变成了[2,4,6,7]。所以Redis可以用于排行榜。

其实 Zset 本身并没有什么好讲的，但是 ZSet 底层用跳跃表这种数据结构来实现，跳跃表就可以好好讲讲了。假如我们用跳跃表这种数据结构来支持 ZSet 这种数据类型，那么在对 ZSet 这个有序集合的插入删除查找都是非常快的。关于跳跃表，我也结合着自己的理解，写了一篇文章：

跳跃表原来就是这玩意儿？-CSDN博客

高可用集群模块

高可用集群模块其实就是主从复制+哨兵机制，还有 AOF 和 RDB 技术。事实上感觉面试的 AOF和 RDB 技术这两个问的多一点，而主从复制+哨兵机制问的并不算多，也有可能是主从复制+哨兵机制相对而言比较复杂吧。关于 Redis 实现高可用的思想和 kafka 消息队列很像，特别是主从复制+哨兵机制那一块，感觉一模一样哈哈哈。

高可扩展集群模块

这个模块也没什么好讲的，Redis 就是通过数据分片来实现高扩展的。这一块感觉面试也问的不多，所以我也仅仅是做了简单的了解，并没有深挖太多。

总结

以上就是我脑图中的 Redis 的6大模块。假如你想要对键值对进行操作，首先你需要通过访问模块（网络IO单线程模型），然后你才可以进入到 Redis 的内部。在 Redis 内部，键值对是怎么存放的呢？其实是通过全局哈希表来存放所有键值对的，我也配了图，这就是索引模块。知道了 Redis 里面长什么样了，就到了真正对键值对进行操作了，操作模块其实就是一些简单的操作（ put、get、delete ），加上 value 中不同数据类型提供的一些不同的操作。最后是存储模块，存储模块研究的问题是 value 中的值是用什么结构进行存储的，我们研究了5种数据类型以及这5种数据类型背后的6种底层数据结构，我也配了图，顺便说了一下这5种数据类型的一些使用场景。

其实这篇文章还没写完，但是 CSDN 的文章评分机制是，如果写太长的话，文章评分会降低，然后影响推流，所以我只好拆开来写了。