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

因為我們公司使用的內(nèi)存數(shù)據(jù)庫是自研的，按理說我對Redis的關(guān)注其實并不算多，但是因為Redis用的比較廣泛，所以我需要了解一下這樣方便我進行面試。

總不能候選人用過Redis，但是我非要問人家阿里的Tair是怎么回事吧。

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

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

本文就來分析下這些問題以及背后的思考。

Redis為什么最開始被設(shè)計成單線程的？

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

很多人說Redis是單線程的，就認為Redis中所有模塊的操作都是單線程的，其實這是不對的。

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

所以說，Redis中并不是沒有多線程模型的，早在Redis 4.0的時候就已經(jīng)針對部分命令做了多線程化。

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

這個問題的答案比較簡單！因為："沒必要！"

為什么沒必要呢？我們先來說一下，什么情況下要使用多線程？

多線程適用場景

一個計算機程序在執(zhí)行的過程中，主要需要進行兩種操作分別是讀寫操作和計算操作。

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

而多線程的目的，就是通過并發(fā)的方式來提升I/O的利用率和CPU的利用率。

那么，Redis需不需要通過多線程的方式來提升提升I/O的利用率和CPU的利用率呢？

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

所以，通過多線程技術(shù)來提升Redis的CPU利用率這一點是完全沒必要的。

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

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

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

多線程的弊端

我們在很多文章中介紹過一些Java中的多線程技術(shù)，如內(nèi)存模型、鎖、CAS等，這些都是Java中提供的一些在多線程情況下保證線程安全的技術(shù)。

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

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

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

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

小結(jié)

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

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

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

Redis的多路復(fù)用

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

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

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

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



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

也就是說，通過一個線程來處理多個IO流。

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

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



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



一旦有請求到達，就會交給 Redis 線程處理，這就實現(xiàn)了一個 Redis 線程處理多個 IO 流的效果。

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

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

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

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

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

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

為什么Redis 6.0 引入多線程

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

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

但是，不知道會不會有人有這樣的疑問：

Redis不是號稱單線程也有很高的性能么？

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

主要是因為我們對Redis有著更高的要求。

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

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

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

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

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



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

雖然現(xiàn)在很多服務(wù)器都是多個CPU核的，但是對于Redis來說，因為使用了單線程，在一次數(shù)據(jù)操作的過程中，有大量的CPU時間片是耗費在了網(wǎng)絡(luò)IO的同步處理上的，并沒有充分的發(fā)揮出多核的優(yōu)勢。

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

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

但是，Redis 的多 IO 線程只是用來處理網(wǎng)絡(luò)請求的，對于讀寫命令，Redis 仍然使用單線程來處理。

那么，在引入多線程之后，如何解決并發(fā)帶來的線程安全問題呢？

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

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

參考資料：

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

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

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

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