【Redis】：Redis为什么能那么快？

Joyo

Redis数据库

发布于：2019年12月15日

次浏览

字数：2.8k字

时长：9分钟

思考问题：

Redis内部是怎样的设计才能单机抗下10W+的qbs?
多核CPU下，Redis为什么要设计成单线程的？
Redis下的IO多路复用技术是怎样的工作流程呢？

Github issues:https://github.com/littlejoyo/Blog/issues/

1.Redis为什么这么快的原因？

1.Redis是基于内存的，内存的读写速度非常快；
2.Redis是单线程的，省去了很多上下文切换线程的时间；
3.Redis使用多路复用技术，可以处理并发的连接，避免请求的阻塞。

2.为什么Redis是单线程的？

2.1 官方答案

因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。
既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

2.2 详细介绍

1）单线程下不需要各种锁的性能消耗

Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作
比如在很长的列表后面添加一个元素，在hash当中添加或者删除一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。
总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁释放锁操作，不会轻易出现死锁而导致的性能消耗。

2）单线程多进程集群方案

单线程的威力实际上非常强大，单核cpu效率也非常高，多线程自然是可以比单线程有更高的性能上限
但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。
所以单线程、多进程的集群不失为一个时髦的解决方案。

3）CPU消耗

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。
但是如果CPU成为Redis瓶颈，或者不想让服务器其他CUP核闲置，那怎么办？
可以考虑多起几个Redis进程，多核就对应多个Redis进程，Redis是key-value数据库，不是关系数据库，数据之间没有约束。
只要客户端分清哪些key放在哪个Redis进程上就可以了。

3.单线程设计的优势和劣势？

3.1 优势：

代码更清晰，处理逻辑更简单
不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗
不存在多进程或者多线程导致的切换而消耗CPU

3.2 劣势：

无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善；

4.Redis下的多路复用IO技术

Redis 采用网络IO多路复用技术来保证在多连接的时候，系统的高吞吐量。
多路-指的是多个socket连接，复用-指的是复用一个线程。
多路复用主要有三种技术：select，poll，epoll（操作系统下）。
采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗），且Redis在内存中操作数据的速度非常快（内存内的操作不会成为这里的性能瓶颈），以上两点也就成就了Redis具有很高的吞吐量。

5.什么是多路复用IO？

关于I/O多路复用(又被称为“事件驱动”)，首先要理解的是，操作系统为你提供了一个功能，当你的某个socket可读或者可写的时候，它可以给你一个通知。
这样当配合非阻塞的socket使用时，只有当系统通知我哪个描述符可读了，我才去执行read操作，可以保证每次read都能读到有效数据而不做纯返回-1和EAGAIN的无用功。
写操作类似。操作系统的这个功能通过select/poll/epoll/kqueue之类的系统调用函数来使用，这些函数都可以同时监视多个描述符的读写就绪状况
这样，多个描述符的I/O操作都能在一个线程内并发交替地顺序完成，这就叫I/O多路复用，这里的“复用”指的是复用同一个线程。

还是理解不了的，根据一个生活实例来加强理解

5.1 举例理解多路复用IO

假设你是一个老师，让30个学生解答一道题目，然后检查学生做的是否正确，你有下面几个选择：
1. 第一种选择：按顺序逐个检查，先检查A，然后是B，之后是C、D。。。这中间如果有一个学生卡主，全班都会被耽误。这种模式就好比，你用循环挨个处理socket，根本不具有并发能力。
1. 第二种选择：你创建30个分身，每个分身检查一个学生的答案是否正确。这种类似于为每一个用户创建一个进程或者线程处理连接。
1. 第三种选择，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。
第三种选择就是IO复用模型，Linux下的select、poll和epoll就是干这个的。将用户socket对应的fd注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。
这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor模式。

6.多路复用IO模型的再了解

6.1 工作流程

Redis客户端先去select循环询问服务端是否可以发起read,这个过程是阻塞的但是速度很快
当服务端准备好了数据报告诉客户端readable(可读)，客户端即可发起read请求，此时因为服务端已经准备好了数据报，直接返回即可。
整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的。这种方式避免了线程的阻塞，又称为非阻塞I/O模型
这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。
采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗）

6.2 多路复用IO的流程图：

用户首先将需要进行IO操作的socket添加到select中，然后阻塞等待select系统调用返回。
当数据到达时，socket被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。
这样用户可以注册多个socket，然后不断地调用select读取被激活的socket，redis服务端将这些socke置于队列中，然后，文件事件分派器，依次去队列中取，转发到不同的事件处理器中，提高读取效率。

6.2.1 工作流程：

1.客户端select机制循环请求
2.去请求服务端询问是否可以read
3.此时没有数据
4.数据报准备完成
5.服务端告诉客户端可以read了
6.1~5 这个过程是阻塞的
7.客户端发起read
8.系统调用read
9.复制数据报
10.复制完成
11.返回成功
12.客户端处理数据报

7.Redis高并发的总结

1. Redis是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在IO上，所以读取速度快。
1. 再说一下IO，Redis使用的是非阻塞IO，IO多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争。
1. Redis采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。
1. 另外，数据结构也帮了不少忙，Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。
1. 还有一点，Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。

8.为什么Redis在4.0版本中加入了多线程的支持呢？

在 Redis 4.0 之后的版本，情况就有了一些变动，新版的 Redis 服务在执行一些命令时就会使用『主处理线程』之外的其他线程，例如 UNLINK、FLUSHALL ASYNC、FLUSHDB ASYNC 等非阻塞的删除操作。

引入多线程的应用场景主要是针对于删除操作
一般情况下，我们可以在 Redis 在中使用 DEL 命令来删除一个键对应的值，如果待删除的键值对占用了较小的内存空间，那么哪怕是同步地删除这些键值对也不会消耗太多的时间。
但是，对于 Redis 中的一些超大键值对，几十 MB 或者几百 MB 的数据并不能在几毫秒的时间内处理完，Redis 可能会需要在释放内存空间上消耗较多的时间，这些操作就会阻塞待处理的任务，影响 Redis 服务处理请求的可用性。
然而，释放内存空间的工作其实可以由后台线程异步进行处理，这也就是UNLINK命令的实现原理，它只会将键从元数据中删除，真正的删除操作会在后台异步执行。