Redis 為什么這么快?

Chaya：“Redis 為什么這么快呢？”

我是 Redis，如今已經成為軟件系統必備的中間件之一，是面試官青睞的對象。本節從面試角度提煉知識點，帶你融會貫通。

65 哥前段時間去面試某大廠，被問到“Redis 的性能為什么這么快”。

65 哥：“額……因為它是基于內存操作數據的，內存速度很快。”

面試官：“還有呢？”

很多人僅僅知道Redis 基于內存實現，并不了解其核心原因。今日，我帶你一起探索真正的原因。

正文開始……

根據官方數據，Redis 的每秒請求數（Qequests Per Second，QPS）可以達到 100000。

1.基于內存實現

讀、寫操作都是在內存上完成的，內存直接由 CPU 控制，也就是由 CPU 內部集成內存控制器，所以說內存是直接與 CPU 對接的，享受與 CPU 通信的“最優帶寬”。

Redis 將數據存儲在內存中，讀/寫操作不會被磁盤的 I/O 速度限制。如下圖是磁盤操作調用棧。

2.I/O 多路復用模型

Redis 采用 I/O多路復用技術并發處理連接。采用 epoll + 自己實現的簡單的事件框架。

將 epoll 中的讀、寫、關閉、連接都轉化成事件，再利用 epoll 的多路復用特性實現一個ae高性能網絡事件處理框架，絕不在 I/O 上浪費一點時間。

“多路”指多個 socket 連接，“復用”指共同使用一個線程。多路復用主要有select、poll和epoll 三種技術。

epoll的基本原理是，內核不監視應用程序本身的連接，而是監視應用程序的文件描述符。

客戶端在運行時會生成具有不同事件類型的套接字。在服務器端，I/O 多路復用程序（I/O 多路復用模塊）會將消息放入隊列（圖2-53中的I/O 多路復用程序的 socket 隊列），然后通過文件事件分派器將其轉發到不同的事件處理器。

Redis 線程不會阻塞在某一個特定的監聽或已連接套接字上，也就是說，不會阻塞在某一個特定的客戶端請求處理上。

正因如此，Redis 可以同時和多個客戶端連接并處理請求，從而提升并發能力。

3.單線程模型

65 哥：“為什么 Redis 不采用多線程并行執行，以充分利用 CPU 呢？”

單線程指 Redis 的網絡 I/O 以及field-value pairs命令讀/寫是由一個線程來執行的。

Redis 的持久化、集群數據同步、異步刪除等操作都是其他線程執行的。

不過Redis從 6.0 版本開始支持多線程模型，需要注意的是，Redis 多 I/O 線程模型只用來處理網絡讀/寫請求，Redis 的讀/寫命令依然是單線程處理的。

使用多線程，通常可以增加系統吞吐量，充分利用 CPU 資源。

但是如果沒有良好的系統設計，就可能出現圖2-54所示的場景：在增加線程數量的初期，吞吐量隨之增加，當進一步增加線程數量時，系統吞吐量幾乎不再增加，甚至下降！

Redis 選擇使用單線程處理命令以及高性能的主要原因如下。

◎   不會因為創建線程消耗性能。

◎   避免上下文切換引起的 CPU 消耗，沒有多線程切換的開銷。

◎   避免了線程之間的競爭問題，例如添加鎖、釋放鎖、死鎖等，不需要考慮各種鎖問題。

◎   代碼更清晰，處理邏輯簡單。

使用 Redis 時，幾乎不存在 CPU 成為瓶頸的情況，Redis 的性能瓶頸主要受限于內存和網絡。

單線程機制讓 Redis 內部實現的復雜度大大降低，漸進式 Rehash、Lpush 等線程不安全的命令都可以無鎖進行。

4.高效的數據結構

65 哥：“為了提高檢索速度，MySQL 使用了 B+ Tree 數據結構，所以 Redis 速度快應該也跟數據結構有關。”

回答正確，這里所說的數據結構并不是 Redis 提供給我們使用的 5 種數據類型 String、Lists、Hashes、Sets和Sorted Sets。

為了在性能和內存之間取得平衡，有的數據類型底層使用了不止一種數據結構，如圖2-55所示。

5.全局散列表

Redis 通過一個散列表來保存所有的key-value，散列表的本質就是數組 + 鏈表，數組的槽位被叫作哈希桶。每個桶的 entry 保存指向具體key和value的指針。

key 是 String 類型，value 的數據類型可以是 5 種中的任意一種。如圖所示。

全局散列表的時間復雜度是 O(1)。通過計算每個鍵的哈希值，可以知道對應的哈希桶位置，再通過哈希桶的 entry 找到對應的數據，這也是 Redis“快”的原因之一。

6.Redis I/O多線程模型

我們已經知道，Redis 使用全局 dict + 內存數據庫 + 豐富高效的數據結構 + 單線程模型 + I/O 多路復用事件驅動框架“快到飛起”。

Redis 的網絡 I/O及key-value命令讀/寫是由單個線程來執行的，避免了不必要的線程上下文切換和資源競爭，對于提升性能有很大幫助。

然而，Redis 官方在 2020 年 5 月正式推出 6.0 版本，引入了 I/O 多線程模型。

現在，咱們就詳細地聊一下 I/O 多線程模型帶來的效果到底是“林黛玉騎鬼火，該強強，該弱弱”；還是“光明頂身懷絕技的張無忌，招招都是必殺技”。

隨著底層網絡硬件性能的提升，Redis 的性能瓶頸逐漸體現在網絡 I/O 的讀/寫上，單個線程處理網絡讀/寫的速度跟不上底層網絡硬件執行的速度。

讀/寫網絡的讀/寫系統調用占用了 Redis 執行期間大部分 CPU 時間，所以 Redis 采用多個 I/O 線程來處理網絡請求，提高網絡請求處理的并行度。

需要注意的是，Redis 多 I/O 線程模型只用來處理網絡讀/寫請求，對于 Redis 的讀/寫命令，依然由單線程處理。

主線程與 I/O 多線程共同協作處理命令的架構圖如圖所示。