Redis是目前廣為人知的一個(gè)內(nèi)存數(shù)據(jù)庫(kù)，在各個(gè)場(chǎng)景中都有著非常豐富的應(yīng)用，前段時(shí)間Redis推出了6.0的版本，在新版本中采用了多線(xiàn)程模型。

因?yàn)槲覀児臼褂玫膬?nèi)存數(shù)據(jù)庫(kù)是自研的，按理說(shuō)我對(duì)Redis的關(guān)注其實(shí)并不算多，但是因?yàn)镽edis用的比較廣泛，所以我需要了解一下這樣方便我進(jìn)行面試。

總不能候選人用過(guò)Redis，但是我非要問(wèn)人家阿里的Tair是怎么回事吧。

所以，在Redis 6.0 推出之后，我想去了解下為什么采用多線(xiàn)程，現(xiàn)在采用的多線(xiàn)程和以前版本有什么區(qū)別？為什么這么晚才使用多線(xiàn)程？

Redis不是已經(jīng)采用了多路復(fù)用技術(shù)嗎？不是號(hào)稱(chēng)很高的性能了嗎？為啥還要采用多線(xiàn)程模型呢？

本文就來(lái)分析下這些問(wèn)題以及背后的思考。

Redis為什么最開(kāi)始被設(shè)計(jì)成單線(xiàn)程的？

Redis作為一個(gè)成熟的分布式緩存框架，它由很多個(gè)模塊組成，如網(wǎng)絡(luò)請(qǐng)求模塊、索引模塊、存儲(chǔ)模塊、高可用集群支撐模塊、數(shù)據(jù)操作模塊等。

很多人說(shuō)Redis是單線(xiàn)程的，就認(rèn)為Redis中所有模塊的操作都是單線(xiàn)程的，其實(shí)這是不對(duì)的。

我們所說(shuō)的Redis單線(xiàn)程，指的是"其網(wǎng)絡(luò)IO和鍵值對(duì)讀寫(xiě)是由一個(gè)線(xiàn)程完成的"，也就是說(shuō)，Redis中只有網(wǎng)絡(luò)請(qǐng)求模塊和數(shù)據(jù)操作模塊是單線(xiàn)程的。而其他的如持久化存儲(chǔ)模塊、集群支撐模塊等是多線(xiàn)程的。

所以說(shuō)，Redis中并不是沒(méi)有多線(xiàn)程模型的，早在Redis 4.0的時(shí)候就已經(jīng)針對(duì)部分命令做了多線(xiàn)程化。

那么，為什么網(wǎng)絡(luò)操作模塊和數(shù)據(jù)存儲(chǔ)模塊最初并沒(méi)有使用多線(xiàn)程呢？

這個(gè)問(wèn)題的答案比較簡(jiǎn)單！因?yàn)椋?沒(méi)必要！"

為什么沒(méi)必要呢？我們先來(lái)說(shuō)一下，什么情況下要使用多線(xiàn)程？

多線(xiàn)程適用場(chǎng)景

一個(gè)計(jì)算機(jī)程序在執(zhí)行的過(guò)程中，主要需要進(jìn)行兩種操作分別是讀寫(xiě)操作和計(jì)算操作。

其中讀寫(xiě)操作主要是涉及到的就是I/O操作，其中包括網(wǎng)絡(luò)I/O和磁盤(pán)I/O。計(jì)算操作主要涉及到CPU。

而多線(xiàn)程的目的，就是通過(guò)并發(fā)的方式來(lái)提升I/O的利用率和CPU的利用率。

那么，Redis需不需要通過(guò)多線(xiàn)程的方式來(lái)提升提升I/O的利用率和CPU的利用率呢？

首先，我們可以肯定的說(shuō)，Redis不需要提升CPU利用率，因?yàn)?strong>Redis的操作基本都是基于內(nèi)存的，CPU資源根本就不是Redis的性能瓶頸。

所以，通過(guò)多線(xiàn)程技術(shù)來(lái)提升Redis的CPU利用率這一點(diǎn)是完全沒(méi)必要的。

那么，使用多線(xiàn)程技術(shù)來(lái)提升Redis的I/O利用率呢？是不是有必要呢？

Redis確實(shí)是一個(gè)I/O操作密集的框架，他的數(shù)據(jù)操作過(guò)程中，會(huì)有大量的網(wǎng)絡(luò)I/O和磁盤(pán)I/O的發(fā)生。要想提升Redis的性能，是一定要提升Redis的I/O利用率的，這一點(diǎn)毋庸置疑。

但是，提升I/O利用率，并不是只有采用多線(xiàn)程技術(shù)這一條路可以走！

多線(xiàn)程的弊端

我們?cè)诤芏辔恼轮薪榻B過(guò)一些Java中的多線(xiàn)程技術(shù)，如內(nèi)存模型、鎖、CAS等，這些都是Java中提供的一些在多線(xiàn)程情況下保證線(xiàn)程安全的技術(shù)。

線(xiàn)程安全：是編程中的術(shù)語(yǔ)，指某個(gè)函數(shù)、函數(shù)庫(kù)在并發(fā)環(huán)境中被調(diào)用時(shí)，能夠正確地處理多個(gè)線(xiàn)程之間的共享變量，使程序功能正確完成。

和Java類(lèi)似，所有支持多線(xiàn)程的編程語(yǔ)言或者框架，都不得不面對(duì)的一個(gè)問(wèn)題，那就是如何解決多線(xiàn)程編程模式帶來(lái)的共享資源的并發(fā)控制問(wèn)題。

雖然，采用多線(xiàn)程可以幫助我們提升CPU和I/O的利用率，但是多線(xiàn)程帶來(lái)的并發(fā)問(wèn)題也給這些語(yǔ)言和框架帶來(lái)了更多的復(fù)雜性。而且，多線(xiàn)程模型中，多個(gè)線(xiàn)程的互相切換也會(huì)帶來(lái)一定的性能開(kāi)銷(xiāo)。

所以，在提升I/O利用率這個(gè)方面上，Redis并沒(méi)有采用多線(xiàn)程技術(shù)，而是選擇了多路復(fù)用 I/O技術(shù)。

小結(jié)

Redis并沒(méi)有在網(wǎng)絡(luò)請(qǐng)求模塊和數(shù)據(jù)操作模塊中使用多線(xiàn)程模型，主要是基于以下四個(gè)原因：

• 1、Redis 操作基于內(nèi)存，絕大多數(shù)操作的性能瓶頸不在 CPU
• 2、使用單線(xiàn)程模型，可維護(hù)性更高，開(kāi)發(fā)，調(diào)試和維護(hù)的成本更低
• 3、單線(xiàn)程模型，避免了線(xiàn)程間切換帶來(lái)的性能開(kāi)銷(xiāo)
• 4、在單線(xiàn)程中使用多路復(fù)用 I/O技術(shù)也能提升Redis的I/O利用率

還是要記?。篟edis并不是完全單線(xiàn)程的，只是有關(guān)鍵的網(wǎng)絡(luò)IO和鍵值對(duì)讀寫(xiě)是由一個(gè)線(xiàn)程完成的。

Redis的多路復(fù)用

多路復(fù)用這個(gè)詞，相信很多人都不陌生。我之前的很多文章中也夠提到過(guò)這個(gè)詞。

其中在介紹Linux IO模型的時(shí)候我們提到過(guò)它、在介紹HTTP/2的原理的時(shí)候，我們也提到過(guò)他。

那么，Redis的多路復(fù)用技術(shù)和我們之前介紹的又有什么區(qū)別呢？

這里先講講Linux多路復(fù)用技術(shù)，就是多個(gè)進(jìn)程的IO可以注冊(cè)到同一個(gè)管道上，這個(gè)管道會(huì)統(tǒng)一和內(nèi)核進(jìn)行交互。當(dāng)管道中的某一個(gè)請(qǐng)求需要的數(shù)據(jù)準(zhǔn)備好之后，進(jìn)程再把對(duì)應(yīng)的數(shù)據(jù)拷貝到用戶(hù)空間中。



多看一遍上面這張圖和上面那句話(huà)，后面可能還會(huì)用得到。

也就是說(shuō)，通過(guò)一個(gè)線(xiàn)程來(lái)處理多個(gè)IO流。

IO多路復(fù)用在Linux下包括了三種，select、poll、epoll，抽象來(lái)看，他們功能是類(lèi)似的，但具體細(xì)節(jié)各有不同。

其實(shí)，Redis的IO多路復(fù)用程序的所有功能都是通過(guò)包裝操作系統(tǒng)的IO多路復(fù)用函數(shù)庫(kù)來(lái)實(shí)現(xiàn)的。每個(gè)IO多路復(fù)用函數(shù)庫(kù)在Redis源碼中都有對(duì)應(yīng)的一個(gè)單獨(dú)的文件。



在Redis 中，每當(dāng)一個(gè)套接字準(zhǔn)備好執(zhí)行連接應(yīng)答、寫(xiě)入、讀取、關(guān)閉等操作時(shí)，就會(huì)產(chǎn)生一個(gè)文件事件。因?yàn)橐粋€(gè)服務(wù)器通常會(huì)連接多個(gè)套接字，所以多個(gè)文件事件有可能會(huì)并發(fā)地出現(xiàn)。



一旦有請(qǐng)求到達(dá)，就會(huì)交給 Redis 線(xiàn)程處理，這就實(shí)現(xiàn)了一個(gè) Redis 線(xiàn)程處理多個(gè) IO 流的效果。

所以，Redis選擇使用多路復(fù)用IO技術(shù)來(lái)提升I/O利用率。

而之所以Redis能夠有這么高的性能，不僅僅和采用多路復(fù)用技術(shù)和單線(xiàn)程有關(guān)，此外還有以下幾個(gè)原因：

1、完全基于內(nèi)存，絕大部分請(qǐng)求是純粹的內(nèi)存操作，非?？焖佟?/p>

2、數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，對(duì)數(shù)據(jù)操作也簡(jiǎn)單，如哈希表、跳表都有很高的性能。

3、采用單線(xiàn)程，避免了不必要的上下文切換和競(jìng)爭(zhēng)條件，也不存在多進(jìn)程或者多線(xiàn)程導(dǎo)致的切換而消耗 CPU

4、使用多路I/O復(fù)用模型

為什么Redis 6.0 引入多線(xiàn)程

2020年5月份，Redis正式推出了6.0版本，這個(gè)版本中有很多重要的新特性，其中多線(xiàn)程特性引起了廣泛關(guān)注。

但是，需要提醒大家的是，Redis 6.0中的多線(xiàn)程，也只是針對(duì)處理網(wǎng)絡(luò)請(qǐng)求過(guò)程采用了多線(xiàn)程，而數(shù)據(jù)的讀寫(xiě)命令，仍然是單線(xiàn)程處理的。

但是，不知道會(huì)不會(huì)有人有這樣的疑問(wèn)：

Redis不是號(hào)稱(chēng)單線(xiàn)程也有很高的性能么？

不是說(shuō)多路復(fù)用技術(shù)已經(jīng)大大的提升了IO利用率了么，為啥還需要多線(xiàn)程？

主要是因?yàn)槲覀儗?duì)Redis有著更高的要求。

根據(jù)測(cè)算，Redis 將所有數(shù)據(jù)放在內(nèi)存中，內(nèi)存的響應(yīng)時(shí)長(zhǎng)大約為 100 納秒，對(duì)于小數(shù)據(jù)包，Redis 服務(wù)器可以處理 80,000 到 100,000 QPS，這么高的對(duì)于 80% 的公司來(lái)說(shuō)，單線(xiàn)程的 Redis 已經(jīng)足夠使用了。

但隨著越來(lái)越復(fù)雜的業(yè)務(wù)場(chǎng)景，有些公司動(dòng)不動(dòng)就上億的交易量，因此需要更大的 QPS。

為了提升QPS，很多公司的做法是部署Redis集群，并且盡可能提升Redis機(jī)器數(shù)。但是這種做法的資源消耗是巨大的。

而經(jīng)過(guò)分析，限制Redis的性能的主要瓶頸出現(xiàn)在網(wǎng)絡(luò)IO的處理上，雖然之前采用了多路復(fù)用技術(shù)。但是我們前面也提到過(guò)，多路復(fù)用的IO模型本質(zhì)上仍然是同步阻塞型IO模型。

下面是多路復(fù)用IO中select函數(shù)的處理過(guò)程：



從上圖我們可以看到，在多路復(fù)用的IO模型中，在處理網(wǎng)絡(luò)請(qǐng)求時(shí)，調(diào)用 select （其他函數(shù)同理）的過(guò)程是阻塞的，也就是說(shuō)這個(gè)過(guò)程會(huì)阻塞線(xiàn)程，如果并發(fā)量很高，此處可能會(huì)成為瓶頸。

雖然現(xiàn)在很多服務(wù)器都是多個(gè)CPU核的，但是對(duì)于Redis來(lái)說(shuō)，因?yàn)槭褂昧藛尉€(xiàn)程，在一次數(shù)據(jù)操作的過(guò)程中，有大量的CPU時(shí)間片是耗費(fèi)在了網(wǎng)絡(luò)IO的同步處理上的，并沒(méi)有充分的發(fā)揮出多核的優(yōu)勢(shì)。

如果能采用多線(xiàn)程，使得網(wǎng)絡(luò)處理的請(qǐng)求并發(fā)進(jìn)行，就可以大大的提升性能。多線(xiàn)程除了可以減少由于網(wǎng)絡(luò) I/O 等待造成的影響，還可以充分利用 CPU 的多核優(yōu)勢(shì)。

所以，Redis 6.0采用多個(gè)IO線(xiàn)程來(lái)處理網(wǎng)絡(luò)請(qǐng)求，網(wǎng)絡(luò)請(qǐng)求的解析可以由其他線(xiàn)程完成，然后把解析后的請(qǐng)求交由主線(xiàn)程進(jìn)行實(shí)際的內(nèi)存讀寫(xiě)。提升網(wǎng)絡(luò)請(qǐng)求處理的并行度，進(jìn)而提升整體性能。

但是，Redis 的多 IO 線(xiàn)程只是用來(lái)處理網(wǎng)絡(luò)請(qǐng)求的，對(duì)于讀寫(xiě)命令，Redis 仍然使用單線(xiàn)程來(lái)處理。

那么，在引入多線(xiàn)程之后，如何解決并發(fā)帶來(lái)的線(xiàn)程安全問(wèn)題呢？

這就是為什么我們前面多次提到的"Redis 6.0的多線(xiàn)程只用來(lái)處理網(wǎng)絡(luò)請(qǐng)求，而數(shù)據(jù)的讀寫(xiě)還是單線(xiàn)程"的原因。

Redis 6.0 只有在網(wǎng)絡(luò)請(qǐng)求的接收和解析，以及請(qǐng)求后的數(shù)據(jù)通過(guò)網(wǎng)絡(luò)返回給時(shí)，使用了多線(xiàn)程。而數(shù)據(jù)讀寫(xiě)操作還是由單線(xiàn)程來(lái)完成的，所以，這樣就不會(huì)出現(xiàn)并發(fā)問(wèn)題了。

參考資料：

https://www.cnblogs.com/Zzbj/p/13531622.html

https://xie.infoq.cn/article/b3816e9fe3ac77684b4f29348

https://jishuin.proginn.com/p/763bfbd2a1c2 《極客時(shí)間：Redis核心技術(shù)與實(shí)戰(zhàn)》

到此這篇關(guān)于Redis不是一直號(hào)稱(chēng)單線(xiàn)程效率也很高嗎，為什么又采用多線(xiàn)程了？的文章就介紹到這了,更多相關(guān)Redis單線(xiàn)程多線(xiàn)程內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！