redis 的单线程架构

我们都知道 redis 作为缓存，读取速度是非常快的，但是大家知道 redis 的线程架构是怎样的呢？也就是说，redis 是多线程架构还是单线程架构呢？
我们通过一个例子来了解：

首先在 redis 服务器中设置一个 key-value：

127.0.0.1:6379> set hello world

然后分别在两个客户端中同时向 redis 服务器发送请求：

127.0.0.1:6379> incr counter

incr 命令就相当于是 +1 操作，类似前置 ++ 或者后置 ++，我们都知道进行 ++ 操作大致分为三个步骤：从内存中读取变量的值 -> 对变量进行 +1 操作 -> 将修改之后的变量再存储到内存中，但是这三个操作不是原子性操作，也就是说，当多个线程同时对一个相同的变量进行 ++ 操作的时候可能会发生线程不安全的问题。但是在我们的 redis 中不会发生这种问题，因为我们的 redis 服务器的线程架构是单线程架构。

这时有人就会问了，redis 服务器时刻接收上万甚至更多的请求，使用多线程架构不是更快一些吗？是的，对于我们其他的服务来说，使用多线程架构来处理请求速度是由于单线程架构的，但是对于我们的 redis 来说，可能单线程架构才是最优的选择。

为什么这样说呢？我们都知道 redis 作为缓存，读取操作数据都是在内存中的，相较于 MySQL 数据库操作数据是在硬盘中的速度快了上千倍甚至上万倍，也就是 redis I / O 的速度是远快于 MySQL 的，不仅如此，redis 的命令执行速度也是小而快的，不像 MySQL 那样有什么唯一约束什么的，redis 的命令执行速度也是很快的，redis 处理每个请求所占用的时间都是非常短的，所以使用多线程对于速度的提升并不明显，更准确的来说，redis 使用多线程可能还会降低服务器处理请求的速度，因为多线程涉及到线程安全的问题，所以就需要考虑到线程竞争和加锁解锁的问题，这些都是需要消耗时间的，综合上面的原因，所以 redis 选择了使用单线程的架构。

宏观上，redis 服务器同时接收多个客户端发送的请求：

但是微观上客户端发送命令的时间是有先后顺序的：

这种先后次序可能是网路传输速度不同导致的，虽然我多个客户端同时向 redis 服务器发送请求，但是由于网络传输速度不同，导致请求到达 redis 服务器的时间不同，即使这几个客户端的网络传输速度是相同的，redis 服务器同时接收到这几个客户端发送过来的请求，redis 服务器也不会同时处理这些请求，而是根据某种标准对这些请求进行排序，然后一次执行这些请求。

为什么单线程结构还能那么快？

通常来说，单线程的处理能力要比多线程差，但是为什么 redis 的单线程模型能达到每秒万级别的处理能力呢？有以下原因：

1. 纯内存访问。Redis 将所有的数据放在内存中，内存的响应时间大约为 100 纳秒，这是 Redis 能达到每秒万级别的重要基础。
2. 非阻塞 IO。redis 使用 epoll 作为 I/O 多路复用技术的实现，再加上 Redis 自身的事件处理模型将 epoll 中的连接、读写、关闭都转换为事件，不在网络 I/O 上浪费过多的时间，如下图所示：
3. 单线程避免了线程切换和竞态产生的消耗。单线程可以简化数据结构和算法的实现，让程序模型更简单；其次多线程避免了在线程竞争同⼀份共享数据时带来的切换和等待消耗。

虽然 redis 使用单线程架构是优于多线程架构的，但是我们需要知道 redis 为什么会选择单线程以及单线程的弊端：那就是单个命令执行所用的时间不易过长，就像我们前面使用 keys 命令的时候，应尽量避免 keys * 的使用。