单线程的Redis速度为什么快?
公众号:emanjusaka的编程栈
by emanjusaka from https://www.emanjusaka.top/2024/11/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的多线程部分仅用于处理网络数据读写和协议解析。命令执行仍然是在单线程中顺序执行,因此不存在并发安全问题。