Redis 是单线程的！

        Redis 是非常的快的！Redis 是基于内存操作，CPU 不是 Redis 性能瓶颈，内存和网络带宽（因为 IO 时需要使用）才是 Redis 的性能瓶颈。

Redis 为什么不使用多线程？

        因为在多线程的情况下，CPU会在多个线程之间切换（上下文切换）是需要耗时的，大概为 1500 ns 左右，在频繁的线程切换下，就会非常影响效率。而使用单线程可以不用切换，使得 Redis 在单线程的情况下效率是最高的。

总结：对于内存系统来说，如果没有上下文切换效率就是最高的！

官方答复：

• 使用 Redis 时，几乎不存在 CPU 成为瓶颈的情况， Redis 主要受限于内存和网络。

• 在一个普通的 Linux 系统上，Redis 通过使用pipelining 每秒可以处理 100 万个请求，所以如果应用程序主要使用 O(N) 或O(log(N)) 的命令，它几乎不会占用太多 CPU。

• 使用了单线程后，可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。

Redis 6.0 为啥要引入多线程？

随着硬件性能提升，Redis 的性能瓶颈可能出现网络 IO 的读写，也就是：单个线程处理网络读写的速度跟不上底层网络硬件的速度。

读写网络的 read/write 方法在系统调用中占用了 Redis 执行期间大部分CPU 时间，瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向：

• 提高网络 IO 性能。典型的实现比如使用 DPDK 来替代内核网络栈的方式。
• 使用多线程充分利用多核，提高网络请求读写的并行度。典型的实现比如 Memcached。

而第一种替代内核网络战的方式实现起来成本太高。需要将 Redis 源码中和网络相关的部分修改，以支持新的网络协议。

所以，Redis 官方采用多个 IO 线程来处理网请络求，提高网络请求处理的并行度，来提高在网络 IO 方面的速度。

需要注意的是，Redis 多 IO 线程模型只用来处理网络读写请求，对于 Redis 的读写的核心命令，依然是单线程处理。

随着互联网的飞速发展，互联网业务系统所要处理的线上流量越来越大，Redis 的单线程模式会导致系统消耗很多 CPU 时间在网络 I/O 上从而降低吞吐量，要提升 Redis 的性能有两个方向：

• 优化网络 I/O 模块
• 提高机器内存读写的速度

后者依赖于硬件的发展，暂时无解。所以只能从前者下手，网络 I/O 的优化又可以分为两个方向：

• 零拷贝技术或者 DPDK 技术
• 利用多核优势

前者成本太高，需要改动 Redis 网络部分的很多代码。

后者的开发成本低，提高明显。并且在 Redis 的超高效率下（不会占用很多的 CPU 资源），也没必要用前者这么复杂的改动方式去再减少 CPU 的占用。