震惊老外 涡轮增压 Redis 苏炳添开启 这么快又是为什么
苏炳添演入环球级弯道超车 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复线程模型
复线程指 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高效的数据结构
回答正确，这里所说的数据结构并不是 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 多线程独特协作解决命令的架构图如图所示。
