Redis為何選擇單線程？

在Redisv6.0以前，Redis的核心網(wǎng)絡(luò)模型選擇用單線程來實(shí)現(xiàn)。

核心意思就是，對于一個 DB 來說，CPU 通常不會是瓶頸，因?yàn)榇蠖鄶?shù)請求不會是 CPU 密集型的，而是 I/O 密集型。

具體到 Redis的話，如果不考慮 RDB/AOF 等持久化方案，Redis是完全的純內(nèi)存操作，執(zhí)行速度是非?？斓?，因此這部分操作通常不會是性能瓶頸，Redis真正的性能瓶頸在于網(wǎng)絡(luò) I/O，也就是客戶端和服務(wù)端之間的網(wǎng)絡(luò)傳輸延遲，因此 Redis選擇了單線程的 I/O 多路復(fù)用來實(shí)現(xiàn)它的核心網(wǎng)絡(luò)模型。

實(shí)際上更加具體的選擇單線程的原因如下：

避免過多的上下文切換開銷：如果是單線程則可以規(guī)避進(jìn)程內(nèi)頻繁的線程切換開銷，因?yàn)槌绦蚴冀K運(yùn)行在進(jìn)程中單個線程內(nèi)，沒有多線程切換的場景。

避免同步機(jī)制的開銷：如果 Redis選擇多線程模型，又因?yàn)?Redis是一個數(shù)據(jù)庫，那么勢必涉及到底層數(shù)據(jù)同步的問題，則必然會引入某些同步機(jī)制，比如鎖，而我們知道 Redis不僅僅提供了簡單的 key-value 數(shù)據(jù)結(jié)構(gòu)，還有 list、set 和 hash 等等其他豐富的數(shù)據(jù)結(jié)構(gòu)，而不同的數(shù)據(jù)結(jié)構(gòu)對同步訪問的加鎖粒度又不盡相同，可能會導(dǎo)致在操作數(shù)據(jù)過程中帶來很多加鎖解鎖的開銷，增加程序復(fù)雜度的同時還會降低性能。

簡單可維護(hù)：如果 Redis使用多線程模式，那么所有的底層數(shù)據(jù)結(jié)構(gòu)都必須實(shí)現(xiàn)成線程安全的，這無疑又使得 Redis的實(shí)現(xiàn)變得更加復(fù)雜。

總而言之，Redis選擇單線程可以說是多方博弈之后的一種權(quán)衡：在保證足夠的性能表現(xiàn)之下，使用單線程保持代碼的簡單和可維護(hù)性。

Redis真的是單線程？

討論 這個問題前，先看下 Redis的版本中兩個重要的節(jié)點(diǎn)：

Redis 4.0（引入多線程處理異步任務(wù)）

Redis 6.0（正式在網(wǎng)絡(luò)模型中實(shí)現(xiàn) I/O 多線程）

所以，網(wǎng)絡(luò)上說的Redis是單線程，通常是指在Redis 6.0之前，其核心網(wǎng)絡(luò)模型使用的是單線程；而Redis的異步任務(wù)使用的仍是多線程。

Redis在 4.0 版本的時候就已經(jīng)引入了的多線程來做一些異步操作，此舉主要針對的是那些非常耗時的命令，通過將這些命令的執(zhí)行進(jìn)行異步化，避免阻塞單線程的事件循環(huán)。

在 Redis 4.0 之后增加了一些的非阻塞命令如 UNLINK、FLUSHALL ASYNC、FLUSHDB ASYNC。

Redisv6.0為何引入多線程？

很簡單，就是 Redis的網(wǎng)絡(luò) I/O 瓶頸已經(jīng)越來越明顯了。

隨著互聯(lián)網(wǎng)的飛速發(fā)展，互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)所要處理的線上流量越來越大，Redis的單線程模式會導(dǎo)致系統(tǒng)消耗很多 CPU 時間在網(wǎng)絡(luò) I/O 上從而降低吞吐量，要提升 Redis的性能有兩個方向：

優(yōu)化網(wǎng)絡(luò) I/O 模塊

提高機(jī)器內(nèi)存讀寫的速度

后者依賴于硬件的發(fā)展，暫時無解。所以只能從前者下手，網(wǎng)絡(luò) I/O 的優(yōu)化又可以分為兩個方向：

零拷貝技術(shù)或者 DPDK 技術(shù)

利用多核優(yōu)勢

零拷貝技術(shù)有其局限性，無法完全適配 Redis這一類復(fù)雜的網(wǎng)絡(luò) I/O 場景，更多網(wǎng)絡(luò) I/O 對 CPU 時間的消耗和 Linux 零拷貝技術(shù)。而 DPDK 技術(shù)通過旁路網(wǎng)卡 I/O 繞過內(nèi)核協(xié)議棧的方式又太過于復(fù)雜以及需要內(nèi)核甚至是硬件的支持。

因此，利用多核優(yōu)勢成為了優(yōu)化網(wǎng)絡(luò) I/O 性價比最高的方案。