Redis其实就是单线程读，性能咋还那么牛逼呢？

Redis单线程读性能却很强”这个问题,直接结合多个技术社区和官方资料的常见解释进行说明。

需要澄清一个关键点：我们常说的“Redis是单线程”，主要是指其核心的网络I/O（即读取客户端请求和发送回复）和键值数据操作是由一个主线程完成的。 这并不是说整个Redis进程只有一个线程，像持久化、集群数据同步等操作，是由额外的后台线程或子进程处理的（根据知乎“Redis为什么设计成单线程？”等讨论中的普遍解释）。

为什么这个单线程的主模型性能还能如此强悍呢？核心原因可以归结为以下几点：

纯内存操作，速度极快。 这是性能的基石，Redis的所有数据主要存储在内存中，内存的读写速度是纳秒级别的，远超磁盘，这意味着，单线程处理一个请求本身的速度就非常快，瓶颈往往不在CPU，而在于网络I/O，在这种情况下，采用多线程来压榨CPU性能的意义不大,反而会引入复杂性。

避免了多线程的竞争和切换开销。 这是单线程设计的最大优势，多线程编程虽然能利用多核，但会带来巨大的复杂性：线程间共享数据需要加锁（锁竞争），线程本身的创建、切换和同步（上下文切换）会消耗大量CPU时间，Redis的单线程模型天然避免了锁，也没有线程切换的开销，程序执行顺序是可预期的、连续的，这就像是一个办事窗口只有一个业务员，但他手脚极其麻利，且永远不用停下来和同事商量、交接或等待，反而可能比多个配合不好的业务员效率更高，根据知乎上许多分析文章的观点,这种设计带来了极致的代码简洁性和执行效率。

高效的I/O模型：非阻塞I/O与多路复用。 这是单线程能同时处理成千上万个客户端连接的关键，Redis采用了Linux系统提供的epoll（或其同类技术，如kqueue、select）这样的I/O多路复用机制，你可以把它想象成：这个单线程的业务员面前有一个超级对讲机（epoll），这个对讲机可以同时监听成千上万个客户的对讲频道，当某个客户有请求发来时，对讲机就会亮灯提示，业务员就只处理那个有请求的频道，处理完一个，立刻通过对讲机查看下一个有请求的频道，他永远不会傻等着某一个客户慢慢想问题，而是在所有有需求的客户间高速切换服务，这使得单个线程就能以极高的吞吐量处理海量网络连接，网络I/O不再是瓶颈。

优秀的数据结构设计。 Redis的键值对不仅仅是简单的“字符串对应字符串”，它提供了丰富的数据结构（如哈希、列表、集合、有序集合），并且这些数据结构在内存中的实现都非常高效，它的字符串实现采用了SDS（简单动态字符串），获取字符串长度是O(1)时间复杂度；它的哈希表在扩容时采用了渐进式rehash，避免了一次性扩容导致的长时间停顿，这些精心设计的数据结构,使得单线程执行每一个操作本身都尽可能的快。

持久化操作不影响主线程性能。 很多人担心持久化（把数据存到磁盘）会阻塞单线程，Redis提供了RDB和AOF两种方式。RDB持久化是通过fork一个子进程来生成数据快照，子进程负责写磁盘，主进程继续提供服务，几乎不阻塞。AOF日志虽然由主线程写入，但通常只是追加写文件操作，速度很快，并且AOF的日志重写（压缩）也是由后台子进程完成的，这样，耗时的磁盘I/O工作被剥离出去了,保证了主线程的高性能。

Redis的单线程高性能是一个“扬长避短”的经典设计： 它扬的是内存速度的“长”，并利用单线程无锁无切换的“简洁” 来充分发挥这个优势。 它避的是多线程复杂性的“短”，并通过epoll多路复用这个“外挂”来弥补单线程在应对海量连接时可能的不足。 通过子进程处理持久化、精心设计的数据结构作为辅助,共同造就了其惊人的性能。

正如许多技术分析文章所指出的，不能简单地认为“多核时代单线程一定慢”，在Redis的应用场景下（数据在内存、操作原子性高、瓶颈常在I/O），这种单线程模型恰恰是简单、稳定和高性能的最优解，Redis 6.0之后也引入了多线程来处理网络I/O，以应对更高的网络带宽需求，但其核心的数据读写命令执行，依然保持着单线程,这恰恰证明了其核心模型的成功。