蘇炳添上演世界級彎道超車 9.83 刷新亞洲100米田徑賽紀錄，拉爆其他運動員，開啟“渦輪增壓”模式震驚老外！隔著屏幕看依然激動萬分。

圖片

他無疑成了百米程全亞洲跑得最快的男人。

Redis 為什么這么快?

Chaya：“蘇炳添是亞洲跑的最快的人，因為開啟了渦輪增壓，那 Redis 為什么這么快呢？”

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

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

65 哥：“額……因為它是基于內(nèi)存操作數(shù)據(jù)的，內(nèi)存速度很快?！?/p>

面試官：“還有呢？”

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

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

圖片

Redis 的性能強大主要有以下原因。

◎   基于內(nèi)存實現(xiàn)。

◎   使用 I/O 多路復用模型。

◎   單線程模型。

◎    6.0 推出 I/O 多線程模型。

◎   高效的底層數(shù)據(jù)結(jié)構(gòu)。

◎   全局散列表。

01基于內(nèi)存實現(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)用棧。

圖片

02I/O 多路復用模型

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

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

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

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

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

圖片

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

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

03單線程模型

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

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

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

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

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

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

圖片

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

◎   不會因為創(chuàng)建線程消耗性能。

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

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

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

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

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

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

65 哥：“為了提高檢索速度，MySQL 使用了 B+ Tree 數(shù)據(jù)結(jié)構(gòu)，所以 Redis 速度快應該也跟數(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所示。

圖片

05全局散列表

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

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

圖片

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

06Redis I/O多線程模型

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

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

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

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

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

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

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

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

圖片