Redis 為什么這么快?

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

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

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

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

面試官：“還有呢？”

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

正文開(kāi)始……

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

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

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

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

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

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

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

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

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

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

Redis 線程不會(huì)阻塞在某一個(gè)特定的監(jiān)聽(tīng)或已連接套接字上，也就是說(shuō)，不會(huì)阻塞在某一個(gè)特定的客戶端請(qǐng)求處理上。

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

3.單線程模型

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

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

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

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

使用多線程，通?？梢栽黾酉到y(tǒng)吞吐量，充分利用 CPU 資源。

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

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

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

◎   避免上下文切換引起的 CPU 消耗，沒(méi)有多線程切換的開(kāi)銷。

◎   避免了線程之間的競(jìng)爭(zhēng)問(wèn)題，例如添加鎖、釋放鎖、死鎖等，不需要考慮各種鎖問(wèn)題。

◎   代碼更清晰，處理邏輯簡(jiǎn)單。

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

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

回答正確，這里所說(shuō)的數(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 通過(guò)一個(gè)散列表來(lái)保存所有的key-value，散列表的本質(zhì)就是數(shù)組 + 鏈表，數(shù)組的槽位被叫作哈希桶。每個(gè)桶的 entry 保存指向具體key和value的指針。

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

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

6.Redis I/O多線程模型

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

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

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

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

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

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

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

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