苏炳添上演世界级弯道超车 9.83 刷新亚洲100米田径赛纪录，拉爆其他运动员，开启“涡轮增压”模式震惊老外！隔着屏幕看依然激动万分。
图片
他无疑成了百米程全亚洲跑得最快的男人。
Redis 为什么这么快?
Chaya：“苏炳添是亚洲跑的最快的人，因为开启了涡轮增压，那 Redis 为什么这么快呢？”
我是 Redis，如今已经成为软件系统必备的中间件之一，是面试官青睐的对象。本节从面试角度提炼知识点，带你融会贯通。
65 哥前段时间去面试某大厂，被问到“Redis 的性能为什么这么快”。
65 哥：“额……因为它是基于内存操作数据的，内存速度很快。”
面试官：“还有呢？”
很多人仅仅知道Redis 基于内存实现，并不了解其核心原因。今日，我带你一起探索真正的原因。
根据官方数据，Redis 的每秒请求数（Qequests Per Second，QPS）可以达到 100000。
图片
Redis 的性能强大主要有以下原因。
◎ 基于内存实现。
◎ 使用 I/O 多路复用模型。
◎ 单线程模型。
◎ 6.0 推出 I/O 多线程模型。
◎ 高效的底层数据结构。
◎ 全局散列表。
01基于内存实现
读、写操作都是在内存上完成的，内存直接由 CPU 控制，也就是由 CPU 内部集成内存控制器，所以说内存是直接与 CPU 对接的，享受与 CPU 通信的“最优带宽”。
Redis 将数据存储在内存中，读/写操作不会被磁盘的 I/O 速度限制。如下图是磁盘操作调用栈。
图片
02I/O 多路复用模型
Redis 采用 I/O多路复用技术并发处理连接。采用 epoll + 自己实现的简单的事件框架。
将 epoll 中的读、写、关闭、连接都转化成事件，再利用 epoll 的多路复用特性实现一个ae高性能网络事件处理框架，绝不在 I/O 上浪费一点时间。
“多路”指多个 socket 连接，“复用”指共同使用一个线程。多路复用主要有select、poll和epoll 三种技术。
epoll的基本原理是，内核不监视应用程序本身的连接，而是监视应用程序的文件描述符。
客户端在运行时会生成具有不同事件类型的套接字。在服务器端，I/O 多路复用程序（I/O 多路复用模块）会将消息放入队列（图2-53中的I/O 多路复用程序的 socket 队列），然后通过文件事件分派器将其转发到不同的事件处理器。
图片
Redis 线程不会阻塞在某一个特定的监听或已连接套接字上，也就是说，不会阻塞在某一个特定的客户端请求处理上。
正因如此，Redis 可以同时和多个客户端连接并处理请求，从而提升并发能力。
03单线程模型
65 哥：“为什么 Redis 不采用多线程并行执行，以充分利用 CPU 呢？”
单线程指 Redis 的网络 I/O 以及field-value pairs命令读/写是由一个线程来执行的。
Redis 的持久化、集群数据同步、异步删除等操作都是其他线程执行的。
不过Redis从 6.0 版本开始支持多线程模型，需要注意的是，Redis 多 I/O 线程模型只用来处理网络读/写请求，Redis 的读/写命令依然是单线程处理的。
使用多线程，通常可以增加系统吞吐量，充分利用 CPU 资源。
但是如果没有良好的系统设计，就可能出现图2-54所示的场景：在增加线程数量的初期，吞吐量随之增加，当进一步增加线程数量时，系统吞吐量几乎不再增加，甚至下降！
图片
Redis 选择使用单线程处理命令以及高性能的主要原因如下。
◎ 不会因为创建线程消耗性能。
◎ 避免上下文切换引起的 CPU 消耗，没有多线程切换的开销。
◎ 避免了线程之间的竞争问题，例如添加锁、释放锁、死锁等，不需要考虑各种锁问题。
◎ 代码更清晰，处理逻辑简单。
使用 Redis 时，几乎不存在 CPU 成为瓶颈的情况，Redis 的性能瓶颈主要受限于内存和网络。
单线程机制让 Redis 内部实现的复杂度大大降低，渐进式 Rehash、Lpush 等线程不安全的命令都可以无锁进行。
04高效的数据结构
65 哥：“为了提高检索速度，MySQL 使用了 B+ Tree 数据结构，所以 Redis 速度快应该也跟数据结构有关。”
回答正确，这里所说的数据结构并不是 Redis 提供给我们使用的 5 种数据类型 String、Lists、Hashes、Sets和Sorted Sets。
为了在性能和内存之间取得平衡，有的数据类型底层使用了不止一种数据结构，如图2-55所示。
图片
05全局散列表
Redis 通过一个散列表来保存所有的key-value，散列表的本质就是数组 + 链表，数组的槽位被叫作哈希桶。每个桶的 entry 保存指向具体key和value的指针。
key 是 String 类型，value 的数据类型可以是 5 种中的任意一种。如图所示。
图片
全局散列表的时间复杂度是 O(1)。通过计算每个键的哈希值，可以知道对应的哈希桶位置，再通过哈希桶的 entry 找到对应的数据，这也是 Redis“快”的原因之一。
06Redis I/O多线程模型
我们已经知道，Redis 使用全局 dict + 内存数据库 + 丰富高效的数据结构 + 单线程模型 + I/O 多路复用事件驱动框架“快到飞起”。
Redis 的网络 I/O及key-value命令读/写是由单个线程来执行的，避免了不必要的线程上下文切换和资源竞争，对于提升性能有很大帮助。
然而，Redis 官方在 2020 年 5 月正式推出 6.0 版本，引入了 I/O 多线程模型。
现在，咱们就详细地聊一下 I/O 多线程模型带来的效果到底是“林黛玉骑鬼火，该强强，该弱弱”；还是“光明顶身怀绝技的张无忌，招招都是必杀技”。
随着底层网络硬件性能的提升，Redis 的性能瓶颈逐渐体现在网络 I/O 的读/写上，单个线程处理网络读/写的速度跟不上底层网络硬件执行的速度。
读/写网络的读/写系统调用占用了 Redis 执行期间大部分 CPU 时间，所以 Redis 采用多个 I/O 线程来处理网络请求，提高网络请求处理的并行度。
需要注意的是，Redis 多 I/O 线程模型只用来处理网络读/写请求，对于 Redis 的读/写命令，依然由单线程处理。
主线程与 I/O 多线程共同协作处理命令的架构图如图所示。
图片
