redis是单线程为什么那么快？

它不仅仅是基于内存，是单线程，核心是利用I/O多路复用的网络模型，让单线程高效处理海量连接。然后在Redis6.0之后，引入多线程处理网络I/O以突破新的瓶颈。但是核心命令执行依旧是单线程，保证数据安全。

 

本质1:Redis的核心瓶颈从来不是CPU，而是网络I/O.

redis的单线程模型指的是其网络I/O和键值对读写时由一个主线程完成的。它之所以能用单线程支撑如此高的并发，关键在于它的核心事件处理模型I/O多路复用。

I/O多路复用：redis利用操作系统提供的机制，让单个线程能够同时监听多个客户端连接的“读写事件”。当有事件发生时线程才去处理，没有事件时线程就阻塞或处理其他任务。

非阻塞I/O：这使得redis可以高效的处理成千上万的并发连接，而不会因为创建大量线程而浪费资源。Redis的性能瓶颈，绝大部分情况下是网络I/O，而不是CPU计算。单线程恰恰是解决网络I/O并发是高效的方式之一，因为它避免了多线程在共享数据时复杂的加锁机制。

 

本质2：单线程的代价与Redis6.0的多线程。

为什么单线程设计近几年被打破了？

瓶颈的转移：随着网络硬件的发展，网络I/O的延迟已经大大降低。同时redis存储的数据越来越复杂，某些操作的CPU消耗开始显现，单线程在应对这些慢操作时会阻塞后续所有请求。

Redis6.0的多线程：它引入的多线程 并不是将读写命令的执行变成多线程。它的多线程只用于处理网络I/O的读写，而核心的命令执行依然是单线程。

这样做既利用了多核CPU来加速网络包的解析，又保持了核心数据结构的线程安全性，避免了锁竞争，这是一个非常精妙的设计。

本质3：面试官想听的是“如何全面评估redis的性能”。

当候选人回答I/O多路复用和redis6.0的演进后，面试官会考察你对性能瓶颈的全面理解。

真正拖垮redis的不是QPS,而是慢查询：命令的复杂度是关键，比如keys*、大集合的交集运算等，这些命令会让单线程的redis陷入长时间阻塞，内存才是真正的资源，虽然CPU不是瓶颈，但内存是，内存不够用导致内存碎片、写时复制导致的性能抖动，以及频繁的淘汰策略，才是生产环境中常见的性能问题。

持久化带来的性能开销，RDB和AOF的持久化机制，尤其是AOF的刷盘策略，会引入磁盘I/O,这才是真正可能成为瓶颈的地方。