[[387557]]

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

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

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

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

Redis不是已經采用了多路復用技術嗎?不是號稱很高的性能了嗎?為啥還要采用多線程模型呢?

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

Redis為什么最開始被設計成單線程的?

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

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

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

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

那么，為什么網絡操作模塊和數據存儲模塊最初并沒有使用多線程呢?

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

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

多線程適用場景

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

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

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

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

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

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

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

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

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

多線程的弊端

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

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

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

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

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

小結

Redis并沒有在網絡請求模塊和數據操作模塊中使用多線程模型，主要是基于以下四個原因：

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

還是要記住：Redis并不是完全單線程的，只是有關鍵的網絡IO和鍵值對讀寫是由一個線程完成的。

Redis的多路復用

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

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

那么，Redis的多路復用技術和我們之前介紹的又有什么區別呢?

這里先講講Linux多路復用技術，就是多個進程的IO可以注冊到同一個管道上，這個管道會統一和內核進行交互。當管道中的某一個請求需要的數據準備好之后，進程再把對應的數據拷貝到用戶空間中。

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

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

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

其實，Redis的IO多路復用程序的所有功能都是通過包裝操作系統的IO多路復用函數庫來實現的。每個IO多路復用函數庫在Redis源碼中都有對應的一個單獨的文件。

在Redis 中，每當一個套接字準備好執行連接應答、寫入、讀取、關閉等操作時，就會產生一個文件事件。因為一個服務器通常會連接多個套接字，所以多個文件事件有可能會并發地出現。

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

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

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

• 1、完全基于內存，絕大部分請求是純粹的內存操作，非?？焖?。
• 2、數據結構簡單，對數據操作也簡單，如哈希表、跳表都有很高的性能。
• 3、采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU
• 4、使用多路I/O復用模型

為什么Redis 6.0 引入多線程

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

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

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

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

不是說多路復用技術已經大大的提升了IO利用率了么，為啥還需要多線程?

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

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

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

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

而經過分析，限制Redis的性能的主要瓶頸出現在網絡IO的處理上，雖然之前采用了多路復用技術。但是我們前面也提到過，多路復用的IO模型本質上仍然是同步阻塞型IO模型。

下面是多路復用IO中select函數的處理過程：

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

雖然現在很多服務器都是多個CPU核的，但是對于Redis來說，因為使用了單線程，在一次數據操作的過程中，有大量的CPU時間片是耗費在了網絡IO的同步處理上的，并沒有充分的發揮出多核的優勢。

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

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

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

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

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

Redis 6.0 只有在網絡請求的接收和解析，以及請求后的數據通過網絡返回給時，使用了多線程。而數據讀寫操作還是由單線程來完成的，所以，這樣就不會出現并發問題了。

參考資料：

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

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

https://jishuin.proginn.com/p/763bfbd2a1c2