单线程的Redis速度为什么快？

0K6gJ7OhP4

博客：https://www.emanjusaka.com
博客园：https://www.cnblogs.com/emanjusaka
公众号：emanjusaka的编程栈

by emanjusaka from  https://www.emanjusaka.com/archives/redis-performance-fast
本文为原创文章，可能会更新知识点以及修正文中的一些错误，全文转载请保留原文地址，避免产生因未即时修正导致的误导。

Redis 是一个采用单线程架构的高性能内存键值数据库。官方测试报告中，单机可支持 10w 左右的 QPS。
为什么单线程设计的 Redis 具有这么高性能？
我们来探讨一下原因是什么。
我将原因归纳为以下的四个方面：

• 单线程架构
  
• 高效的数据结构
  
• 数据存储在内存中
  
• 事件驱动模型
  

下面我们详细分析下每一个方面。
单线程架构

在多线程环境中，操作系统需要频繁地进行线程切换以让不同的线程获得 CPU 时间片来执行任务。线程切换涉及到保存当前线程的状态、恢复另一个线程的状态等操作，这些操作会消耗一定的时间和系统资源。
而单线程的 Redis 完全避免了线程切换带来的开销，从而可以更高效地利用 CPU 资源专注于处理客户端请求。
请注意，当我们强调单线程时，我们指的是使用一个线程来处理网络 I/O 和键值对读写（文件事件调度程序）。
也就是说，一个线程处理所有的网络请求，但Redis的其他功能，比如持久化、异步删除、集群数据同步等，实际上都是由额外的线程来执行的。
高效的数据结构

Redis 的数据结构如字符串（SDS）、字典（哈希表实现）、链表等在设计时就考虑了在单线程环境下的高效操作。
例如，SDS 通过预分配和惰性空间释放策略，减少了内存分配和释放的次数，在单线程环境下可以更高效地进行字符串操作。
字典的哈希表实现采用渐进式 rehash 策略，避免了一次性进行大量数据的重新哈希，在单线程下可以平滑地进行哈希表的扩展和收缩操作，不会因为多线程竞争而导致复杂的同步问题。
Redis 共有 5 种数据类型： String 、 List 、 Hash 、 Set 和 SortedSet 。
不同的数据类型在底层使用一种或多种数据结构来支持，目的是达到更快的速度。
数据存储在内存中

Redis完全基于内存，数据存储在内存中。绝大多数请求都是纯内存操作，速度极快。
与传统的磁盘文件数据存储相比，Redis避免了通过磁盘I/O将数据从磁盘读入内存的开销。
事件驱动模型

使用基于网络 I/O 多路复用（非阻塞 I/O）的线程模型可以处理并发连接，有助于缓解网络 I/O 速度慢的问题。
Redis 使用高效的事件驱动模型（如 epoll、kqueue 等）来处理网络 I/O 和时间事件。
当有客户端连接请求或者数据可读可写时，事件驱动模型会通知 Redis 进行相应的处理。
Redis 6.0 的多线程

Redis采用单线程的方式来实现高可维护性。虽然多线程在某些方面可能表现良好，但它引入了程序执行顺序的不确定性，导致并发读写的一系列问题。这增加了系统的复杂性，并且可能由于线程切换、锁定和解锁甚至死锁而导致性能损失。
Redis 6.0引入了多线程，因为它的瓶颈不在于内存，而在于网络I/O模块，该模块消耗了CPU时间。因此，引入多线程来处理网络I/O，充分利用CPU资源，减少网络I/O阻塞带来的性能损失。
多线程模式下是否存在线程并发问题？
在Redis的多线程模式下，接收、发送和解析命令可以配置为在多个线程中执行，因为它们是我们确定的主要耗时点。然而，涉及内存操作的命令执行仍然在单线程中运行。
因此，Redis的多线程部分仅用于处理网络数据读写和协议解析。命令执行仍然是在单线程中顺序执行，因此不存在并发安全问题。

谦学于心，谷纳万物，静思致远，共筑收获之旅！
原文地址： https://www.emanjusaka.com/archives/redis-performance-fast