10万+QPS 真的只是因为单线程和基于内存？

你以为 Redis 这么快仅仅因为单线程和基于内存？

那么你想得太少了，我个人认为 Redis 的快是基于多方面的：不但是单线程和内存，还有底层的数据结构设计，网络通信的设计，主从、哨兵和集群等等方面的设计~

下面，我将 360° 为你揭开 Redis QPS达到10万/秒的神秘面纱。

首先值得称赞的第一点：Redis 底层使用的数据结构很多，但是却没有直接使用这些数据结构来实现键值对数据库，而是基于数据结构创建了一个对象（redisObject）系统。（是不是觉得有点面向对象编程的意思 ~）

对象系统里面包括了字符串对象，列表对象，哈希对象、集合对象和有序集合对象。

使用对象的好处：

一个对象怎么设置不同的数据结构实现？

在讲解前，我们必须要了解 Redis 对象的结构。

它三个重要的部分：type 属性、encoding 属性，和 ptr 属性。

我们用字符串对象为例：

我们都知道，Redis 的 SET 命令其实是针对字符串的，但是它也可以设置数值。那底层是怎么做的呢？

它会将 String 对象的 encoding 属性标识为 REDIS_ENCODING_INT，表示这个键对应的值是 Long 类型的整数。

而当我们利用 APPEND 命令往值后面添加字符串呢？

此时会将 String 对象的 encoding 属性的标识为 REDIS_ENCODING_RAW，表示这个值此时是简单动态字符串。

正是因为使用对象，通过 type、encoding和prt 属性，使得同一个对象可以适应在不同的场景下，使得不同的改变不需要创建新的键值对，这样使得 Redis 的对象使用效率非常的高。

Redis 的字符串对象采用三种编码：int、embstr 和 raw。

int 编码就不用说了，就是为了兼容 SET 命令可以设置数值。

而 embstr 和 raw 最大的区别就是内存分配操作次数：

Redis 中字符串对象的底层是使用 SDS （Simple Dynamic String）实现的。

SDS 有三部分：

首先介绍一下使用 len 属性和 free 属性的好处：

得益于 SDS 有 len 属性，获取字符串长度的复杂度为 O(1);

得益于 SDS 有 free 属性，可以杜绝缓冲区溢出，字符串扩展前可以根据 free 属性来判断是否满足直接扩展，不满足则需要先执行内存重分配操作，然后再扩展字符串。

我们都知道修改字符串长度很有可能导致触发内存重分配操作，但是 Redis 对于内存重分配有两个优化策略：

空间预分配：

惰性空间释放：

对象中使用数字是非常常见的，例如设置用户的年龄、学生的分数、博客中文章的排名等等。所以 Redis 为了避免重复创建数字对应的字符串对象，它会将一个范围的整数对应的字符串对象用来共享。

目前来说，Redis 会在初始化服务器时，创建一万个字符串对象，这些对象包含了从 0 到 9999 的所有整数值，当服务器需要用到值为 0 到 9999 的字符串对象时，服务器就会使用这些共享对象，而不是新创建对象。

当然了，我们还可以通过修改

我们都知道 Redis 是使用 C 语言开发的，所以 SDS 一样遵循 C 字符串以空字符结尾的惯例，所以 SDS 可以重用很多 库定义的函数。

简单介绍一下 ziplist 的结构：

压缩列表是一种为节约内存而开发的顺序型数据结构，所以在 Redis 里面压缩列表被用做列表键和哈希键的底层实现之一。

正是利用压缩列表，不但使得数据非常紧凑而节约内存，而且还可以利用它的结构来做到非常简单的顺序遍历、逆序遍历，O(1) 复杂度的获取长度和所占内存大小等等。

整数集合（intset）是 Redis 用于保存整数值的集合抽象数据结构，它可以保存类型为 int16_t、int32_t 或者 int64_t 的整数值，并且保证集合中不会出现重复元素。

我们先看看整数集合的结构：

typeof structintset{

虽然 intset 结构将 contents 属性声明为 int8_t类型的数组，但实际上 contents 数组并不保存任何 int8_t 类型的值，contents 数组的真正类型取决于 encoding 属性的值。

intset 一开始不会直接使用最大类型来定义数组，而是利用升级操作，当元素的值达到一定长度时，会重新为数组分配内存空间，并将数组里的旧元素的类型进行升级。

这样做好处：

因为整数集合没有降级操作，所以从另外一个角度看，升级操作其实也会浪费内存：如果整数集合里只有一个数值是 int64_t ，而其他数值都是小于它的，但是整数集合的编码将还是保持 INTSET_ENC_INT64，就是说，小于 int64_t 的整数还是会用 int64_t 的空间来保存。

每当别人问 Redis 为啥这么快？脱口而出的不是基于内存就是基于单线程。

Redis 使用基于 Reactor 模式实现的网络通信，它使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。

当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件分派器就会调用套接字之前关联好的事件处理器来处理这些事件。

因为 Redis 是单线程的，所以I/O多路复用程序会利用队列来控制产生事件的套接字的并发；队列中的套接字以有序、同步、每次一个的方式分派给文件事件分派器。

多种 I/O 复用机制：

常见的 I/O 复用机制有很多种，例如 select、epoll、evport 和 kqueue 等等。

Redis 对上面的多种 I/O 复用机制都进行了各自的封装，在程序编译时会自动选择系统中性能最高的 I/O 多路复用函数库来作为 Redis 的 I/O 多路复用程序的底层实现。

我们都知道，文件事件的发生都是随机的，因为 Redis 服务器永远不可能知道客户端下次发送命令是什么时候，所以程序也不可能一直阻塞着直到发生文件事件。

毕竟 Redis 是单线程的，文件事件的处理和时间事件的处理都在同一个线程里，如果线程被 aeApiPoll 函数一直阻塞着，那么即使时间事件的时间到了，也得不到资源来执行。

所以 Redis 有这么一个策略，aeApiPoll 函数的最大阻塞时间由到达时间最接近当前时间的时间事件决定，这个方法既可以避免服务器对时间事件进行频繁的轮询（忙等待），也可以确保 aeApiPoll 函数不会阻塞过长时间。

对文件事件和时间事件的处理都是同步、有序、原子地执行的，服务器不会中途中断事件处理，也不会对事件进行抢占，因此，不管是文件事件的处理器，还是时间事件的处理器，它们都会尽可地减少程序的阻塞时间，并在有需要时主动让出执行权，从而降低造成事件饥饿的可能性。

Redis 服务器中不少功能是要使用系统的当前时间的，而获取系统当前时间需要执行一次系统调用。

为了减少系统调用，提升性能，服务器状态（redisServer）中的 unixtime 属性和 mstime 属性分别保存了秒级精度的系统当前 UNIX 时间戳和毫秒级精度的系统当前 UNIX 时间戳；然后 serverCron 函数会每隔 100 毫秒更新一次这两个属性。

这两个时间只会用在对时间精确度要求不高的功能上，例如打印日志、计算服务器上线时间等等。像设置键过期时间、添加慢查询日志这种需要时间精确度高的功能上，服务器还是会每次都调用系统来获取。

Redis 2.8 前的复制功能：

缺点：

假设主从服务器断开连接，当从服务器重新连接上后，又要重新执行一遍同步（sync）操作；但是其实，从服务器重新连接时，数据库状态和主服务器大致是一样的，缺少的只是断开连接过程中，主服务器接收到的写命令；每次断线后都需要重新执行一遍完整的同步操作，这样会很浪费主服务器的性能，毕竟 BGSAVE 命令要读取此时主服务器完整的数据库状态。

Redis 2.8 后对复制算法进行了很大的优化：

利用 PSYNC 命令代替 SYNC 命令，将复制操作分为完整重同步和部分重同步。只有当从服务器第一次复制或断开时间过长时，才会执行完整重同步，而从服务器短时间断开重连后，只需要将自己的 offset（复制偏移量）发送给主服务器，主服务器会根据从服务器的 offset 和自己的 offset，然后从复制积压缓冲区里将从服务器丢失的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以将数据库更新至主服务器当前所处的状态。

在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令：REPLCONF ACK ，其中 replication_offet 是从服务器当前的复制偏移量。

心跳检测的三大作用：

min-slaves-to-write3

3、哨兵模式的订阅连接设计

Sentinel 不但会与主从服务器建立命令连接，还会建立订阅连接。

在默认情况下，Sentinel会以每两秒一次的频率，通过命令连接向所有被监视的主服务器和从服务器发送 PUBLISH 命令，命令附带的是 Sentinel 本身的信息和所监听的主服务器的信息；接着接收到此命令的主从服务器会向 __sentinel__:hello 频道发送这些信息。

而其他所有都是监听此主从服务器的 Sentinel 可以通过订阅连接获取到上面的信息。

这也就是说，对于每个与 Sentinel 的服务器，Sentinel 既通过命令连接向服务器的 __sentinel__:hello 频道发送信息（PUBLISH），又通过订阅连接从服务器的 __sentinel__:hello 频道接收信息（SUBSCRIBE）。

通过这种方式，监听同一个主服务器的 Sentinel 们可以互相知道彼此的存在，并且可以根据频道消息更新主服务器实例结构（sentinelRedisInstance）的 sentinels 字典，还可借此与其他 Sentinel 建立命令连接，方便之后关于主服务器下线检查、选举领头 Sentinel 等等的通信。

Redis 集群中的各个节点通过 Gossip 协议来交换各自关于不同节点的状态信息，其中 Gossip 协议由 MEET、PING、PONG 三种消息实现，这三种消息的正文都由两个

利用 Gossip 协议，可以使得集群中节点更新的信息像病毒一样扩散，这样不但扩散速度快，而且不需要每个节点之间都发送一次消息才能同步集群中最新的信息。

至此，我自己能想到的使得 Redis 性能优越的设计都在这里了。当然了，它的厉害之处远远不止这些~

大家都知道，使用 Redis 是非常简单的，来来去去就几个命令，但是当你深入 Redis 底层的设计和实现，你会发现，这真的是一个非常值得大家深究的开源中间件！！！