Redis 為什么這么快?

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

我是 Redis，如今已經(jīng)成為軟件系統(tǒng)必備的中間件之一，是面試官青睞的對象。本節(jié)從面試角度提煉知識點(diǎn)，帶你融會貫通。

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

65 哥：“額……因?yàn)樗腔趦?nèi)存操作數(shù)據(jù)的，內(nèi)存速度很快?！?/p>

面試官：“還有呢？”

很多人僅僅知道Redis 基于內(nèi)存實(shí)現(xiàn)，并不了解其核心原因。今日，我?guī)阋黄鹛剿髡嬲脑颉?/p>

正文開始……

根據(jù)官方數(shù)據(jù)，Redis 的每秒請求數(shù)（Qequests Per Second，QPS）可以達(dá)到 100000。

1.基于內(nèi)存實(shí)現(xiàn)

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

Redis 將數(shù)據(jù)存儲在內(nèi)存中，讀/寫操作不會被磁盤的 I/O 速度限制。如下圖是磁盤操作調(diào)用棧。

2.I/O 多路復(fù)用模型

Redis 采用 I/O多路復(fù)用技術(shù)并發(fā)處理連接。采用 epoll + 自己實(shí)現(xiàn)的簡單的事件框架。

將 epoll 中的讀、寫、關(guān)閉、連接都轉(zhuǎn)化成事件，再利用 epoll 的多路復(fù)用特性實(shí)現(xiàn)一個ae高性能網(wǎng)絡(luò)事件處理框架，絕不在 I/O 上浪費(fèi)一點(diǎn)時間。

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

epoll的基本原理是，內(nèi)核不監(jiān)視應(yīng)用程序本身的連接，而是監(jiān)視應(yīng)用程序的文件描述符。

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

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

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

3.單線程模型

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

單線程指 Redis 的網(wǎng)絡(luò) I/O 以及field-value pairs命令讀/寫是由一個線程來執(zhí)行的。

Redis 的持久化、集群數(shù)據(jù)同步、異步刪除等操作都是其他線程執(zhí)行的。

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

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

但是如果沒有良好的系統(tǒng)設(shè)計(jì)，就可能出現(xiàn)圖2-54所示的場景：在增加線程數(shù)量的初期，吞吐量隨之增加，當(dāng)進(jìn)一步增加線程數(shù)量時，系統(tǒng)吞吐量幾乎不再增加，甚至下降！

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

◎   不會因?yàn)閯?chuàng)建線程消耗性能。

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

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

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

使用 Redis 時，幾乎不存在 CPU 成為瓶頸的情況，Redis 的性能瓶頸主要受限于內(nèi)存和網(wǎng)絡(luò)。

單線程機(jī)制讓 Redis 內(nèi)部實(shí)現(xiàn)的復(fù)雜度大大降低，漸進(jìn)式 Rehash、Lpush 等線程不安全的命令都可以無鎖進(jìn)行。

4.高效的數(shù)據(jù)結(jié)構(gòu)

65 哥：“為了提高檢索速度，MySQL 使用了 B+ Tree 數(shù)據(jù)結(jié)構(gòu)，所以 Redis 速度快應(yīng)該也跟數(shù)據(jù)結(jié)構(gòu)有關(guān)?！?/p>

回答正確，這里所說的數(shù)據(jù)結(jié)構(gòu)并不是 Redis 提供給我們使用的 5 種數(shù)據(jù)類型 String、Lists、Hashes、Sets和Sorted Sets。

為了在性能和內(nèi)存之間取得平衡，有的數(shù)據(jù)類型底層使用了不止一種數(shù)據(jù)結(jié)構(gòu)，如圖2-55所示。

5.全局散列表

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

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

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

6.Redis I/O多線程模型

我們已經(jīng)知道，Redis 使用全局 dict + 內(nèi)存數(shù)據(jù)庫 + 豐富高效的數(shù)據(jù)結(jié)構(gòu) + 單線程模型 + I/O 多路復(fù)用事件驅(qū)動框架“快到飛起”。

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

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

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

隨著底層網(wǎng)絡(luò)硬件性能的提升，Redis 的性能瓶頸逐漸體現(xiàn)在網(wǎng)絡(luò) I/O 的讀/寫上，單個線程處理網(wǎng)絡(luò)讀/寫的速度跟不上底層網(wǎng)絡(luò)硬件執(zhí)行的速度。

讀/寫網(wǎng)絡(luò)的讀/寫系統(tǒng)調(diào)用占用了 Redis 執(zhí)行期間大部分 CPU 時間，所以 Redis 采用多個 I/O 線程來處理網(wǎng)絡(luò)請求，提高網(wǎng)絡(luò)請求處理的并行度。

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

主線程與 I/O 多線程共同協(xié)作處理命令的架構(gòu)圖如圖所示。