Redis 6.0 多線程性能測試結(jié)果及分析

路人甲Java 2022-02-17

展開全文

單線程的Redis一向以簡潔高效著稱，但也有其阿喀琉斯之踵：阻塞！單個線程在最容易產(chǎn)生瓶頸的網(wǎng)絡(luò)讀寫（Redis大key,也包括其他一些重量級的操作sort/sunion/zunionstore/sdiff，集中性的expired key清理，內(nèi)存溢出的maxmemory-policy策略等）請求完成之前，其他所有請求都將會被阻塞，嚴(yán)重影響其效率，因此Redis的多線程呼聲就越來越高。由于是基于內(nèi)存的操作延遲非常低，所以即便是單線程模式下CPU資源也不會是的瓶頸。最容易出現(xiàn)瓶頸的還是網(wǎng)絡(luò)IO操作。在Redis 6.0開始支持多線程之后，所謂的多線程也只是socket層面的多線程，核心的內(nèi)存讀寫還是單線程模式。
弄清楚了多線程的本質(zhì)之后，就會有一系列的問題，多線程會比單線程有多大的提升？設(shè)置多少個線程合適？見一些大神測試過（目前全網(wǎng)也只有美圖做過unstable版本的測試，所有的轉(zhuǎn)載都是來源于這個測試），其結(jié)果也非常理想，但只是看看也不太過癮，決定一試為快，本文將對Redis的多線程進行一個粗淺的測試驗證。同時需要思考另外一個問題：面對多線程版本的Redis，和Redis cluster，該如何選擇？

多線程Redis

redis 6.0 的“多線程”特性讓很多標(biāo)題黨高潮連連，參考圖片源自于：美圖技術(shù)團隊侵刪，核心的線程（Execute Command）還是單線程，多線程是指網(wǎng)絡(luò)IO（socket）讀寫的多線程化。
如下圖所示，讀寫網(wǎng)絡(luò)socket中的數(shù)據(jù)是可以用多個線程，所以Redis的多線程也叫做io thread，相關(guān)參數(shù)：“io-threads”。另一個參數(shù)是io-threads-do-reads，這里涉及另外一個細(xì)節(jié)：多線程IO主要用在請求完成后返回結(jié)果集的過程，也就是socket寫操作，至于讀socket，單線程本身采用的多路IO復(fù)用技術(shù)，也不會產(chǎn)生瓶頸，因此Redis給出了一個io-threads-do-reads 參數(shù)，決定讀socket的時候是否啟用多線程。其實io-threads-do-reads是否啟用，對性能的影響并不大，最后會做一個驗證。

測試環(huán)境及策略

本機配置：centos 7，16C+32GB內(nèi)存

Redis版本：6.0.6

下面分別以1線程，2線程，4線程，6線程，8線程，10線程的配置下，200個并發(fā)連接進行100百萬次請求（./bin/redis-benchmark -d 128 -c 200 -n 1000000 -t set -q ），同時為避免網(wǎng)絡(luò)延遲帶來的影響，redis-benchmark在Redis實例本地，測試Redis的get和set性能。

翻車

整個測試開始之前，經(jīng)歷了兩次翻車才得以繼續(xù)

翻車現(xiàn)場1
centos 7上默認(rèn)的gcc是4.*版本，無法編譯Redis 6.0，所以需要升級gcc，因為本機不支持yum安裝，參考這里使用源碼包安裝，gcc編譯的時候那個酸爽，本機16C+32GB內(nèi)存的環(huán)境下，因為缺少某些依賴包，導(dǎo)致失敗了幾次，最終編譯成功的一次，花了大概1個小時10分鐘

翻車現(xiàn)場2
沒有認(rèn)真讀配置文件中的說明，設(shè)置io-threads后，重啟Redis服務(wù)后，上來就用redis-benchmark直接懟，其結(jié)果跟單線程差不多，令人大跌眼鏡。
最后還是在原始配置文件發(fā)現(xiàn)了這段話：
If you want to test the Redis speedup using redis-benchmark, make sure you also run the benchmark itself in threaded mode, using the --threads option to match the number of Redis threads, otherwise you'll not be able to notice the improvements.

意思是必須在redis-benchmark設(shè)置--threads參數(shù)，并且要match Redis中的線程設(shè)置，--threads參數(shù)是redis 6.0后新增的一個參數(shù)。只有加上--threads這個參數(shù)才能體現(xiàn)出來多線程Redis的效率。

關(guān)于Thread IO的說明

經(jīng)歷了第二次翻車之后決定好好看一看redis.conf中關(guān)于thread io的注釋信息

################################ THREADED I/O #################################

# Redis is mostly single threaded, however there are certain threaded
# operations such as UNLINK, slow I/O accesses and other things that are
# performed on side threads.
#
# Now it is also possible to handle Redis clients socket reads and writes
# in different I/O threads. Since especially writing is so slow, normally
# Redis users use pipelining in order to speed up the Redis performances per
# core, and spawn multiple instances in order to scale more. Using I/O
# threads it is possible to easily speedup two times Redis without resorting
# to pipelining nor sharding of the instance.
#
# By default threading is disabled, we suggest enabling it only in machines
# that have at least 4 or more cores, leaving at least one spare core.
# Using more than 8 threads is unlikely to help much. We also recommend using
# threaded I/O only if you actually have performance problems, with Redis
# instances being able to use a quite big percentage of CPU time, otherwise
# there is no point in using this feature.
#
# So for instance if you have a four cores boxes, try to use 2 or 3 I/O
# threads, if you have a 8 cores, try to use 6 threads. In order to
# enable I/O threads use the following configuration directive:
#
# io-threads 4
#
# Setting io-threads to 1 will just use the main thread as usual.
# When I/O threads are enabled, we only use threads for writes, that is
# to thread the write(2) syscall and transfer the client buffers to the
# socket. However it is also possible to enable threading of reads and
# protocol parsing using the following configuration directive, by setting
# it to yes:
#
# io-threads-do-reads no
#
# Usually threading reads doesn't help much.
#
# NOTE 1: This configuration directive cannot be changed at runtime via
# CONFIG SET. Aso this feature currently does not work when SSL is
# enabled.
#
# NOTE 2: If you want to test the Redis speedup using redis-benchmark, make
# sure you also run the benchmark itself in threaded mode, using the
# --threads option to match the number of Redis threads, otherwise you'll not
# be able to notice the improvements.

大概意思如下：
大多數(shù)情況下redis是以單線程的方式運行的，然而，有一些線程操作，如斷開鏈接，耗時的I/O操作（bgsave，expired key清理之類的操作）和其他任務(wù)是在side線程（主線程fork出來的子線程）中執(zhí)行的。

現(xiàn)在也可以在不同的I/O線程中處理Redis客戶端socket讀和寫。由于寫入（指socket寫入）速度非常慢，Redis用戶通常使用pipelining來提高Redis在單核上的性能，并使用多個實例的方式來擴容。使用I/O線程可以很容易地提升Redis在socket讀寫上的性能，而無需求助于管道或?qū)嵗姆制?/div>

Redis 6.0中默認(rèn)情況下多線程被是被禁用的，建議至少有4個或更多核的機器中啟用多線程，且至少留下1備用核。使用超過8個線程不大可能有太大幫助。

由于Redis實例能夠充分利用CPU資源（譯者注：意思是即便是單線程下，CPU并不是瓶頸），多線程I/O只有在你確實有性能問題的情況下才能提升運行效率，否則就沒有必要使用這個特性。

如果你有一個4核的服務(wù)器，嘗試使用2或3個I/O線程，如果是8核，嘗試使用6個線程。要啟用多線程I/O，請使用以下配置參數(shù)：io-threads 4

設(shè)置io-threads為1會像傳統(tǒng)的redis一樣啟用單個主線程，當(dāng)I/O threads被啟用之后，僅僅支持寫操作（譯者注：指的是socket的寫操作，socket的讀操作使用多路io復(fù)用技術(shù)，本身也不是瓶頸）即IO線程調(diào)用syscall并將客戶端緩沖區(qū)傳輸?shù)絪ocket。但是，也可以啟用讀寫線程，使用以下配置指令進行協(xié)議解析，方法是將其設(shè)置為“yes”：io-threads-do-reads no

通常情況下，threading reads線程對性能的提升幫助并不大

注1：此配置指令不能在運行時通過配置集進行更改，只能在修改配置文件之后重啟。啟用SSL時，當(dāng)前此特性也無效。

注2：如果你想用Redis-benchmark測試Redis的性能，務(wù)必以threaded mode的方式運行Redis-benchmark，使用--threads選項來匹配Redis線程的數(shù)量，否則無法觀察到測試結(jié)果的提升。

測試結(jié)果及分析

如下是不同線程requests per second測試結(jié)果的橫向?qū)Ρ?，分別在不同的線程下，進行100W次get/set請求的QPS結(jié)果

從中可以看到：

1，1個線程，也就是傳統(tǒng)的單線程模式，get 操作的QPS可以達到9W左右

2，2個線程，get 操作的QPS可以達到18W左右，相比單線程有100%+的提升

3，4個線程，與2線程相比，會有30%左右的提高，但是已經(jīng)沒有從1個線程到2個線程翻一倍的提升了

4，6個線程，與4線程相比，沒有明顯的提升，對于SET操作，QPS從4線程到6線程，8線程開始沒有出現(xiàn)明顯的差異，都在23W~24W之間

5，8個線程，與4線程和6線程相比，8線程下大概有10%的提升

6，10個線程，相比效率最高的8線程，此時性能反倒是開始下降了，與4線程或者6線程的效率相當(dāng)
因此在本機環(huán)境下，io-threads 4設(shè)置成2或者4個都o(jì)k，最多不超過8個，超出后性能反而會下降，同時也不能超出cpu的個數(shù)，正如配置文件中注釋中說的，至少要留出一個CPU。

如下是不同線程下10測試結(jié)果中GET和SET的requests per second 平均值對比：

關(guān)于io-threads-do-reads參數(shù)

上文提到過io-threads-do-reads這個參數(shù)，它是決定socket讀操作是否開啟多線程，Redis的socket讀操作采用多路IO復(fù)用技術(shù)，本身不會成為瓶頸，所以這個參數(shù)對多線程下測試影響比較小。依舊參考這里的這個圖侵刪，這個io-threads-do-reads在筆者理解起來，就是socket讀的線程，是否開啟影響不大。
Redis.conf中關(guān)于此參數(shù)的注釋為:When I/O threads are enabled, we only use threads for writes, that is to thread the write(2) syscall and transfer the client buffers to the socket. However it is also possible to enable threading of reads and protocol parsing using the following configuration directive, by setting it to yes Usually threading reads doesn't help much.
以下就該參數(shù)啟用與否進行一次對比測試

參考如下截圖，在開啟了兩個線程的情況下，分別開啟和禁用io-threads-do-reads，從整體上看，性能影響差別很小。當(dāng)然專業(yè)的大神可以從源碼的角度去分析。
io-threads為2，且啟動io-threads-do-reads

io-threads為2，且禁動io-threads-do-reads

多線程版本的Redis和Redis Cluster的選擇

redis集群有兩種模式：sentinel和cluster，這里暫時先不提sentinel，來思考多線程版本的Redis和Redis Cluster的選擇問題。
Redis的Cluster解決的就是擴展性和單節(jié)點單線程的阻塞隱患，如果Redis支持了多線程（目前多線程的Redis最對不建議超出8個線程），在不考慮單個節(jié)點網(wǎng)卡瓶頸的情況下，其實這兩個問題都已經(jīng)解決了，單節(jié)點可以支持多線程和充分利用多核CPU，單節(jié)點可以支持到25W QPS，還要啥自行車？
同時要考慮到Redis cluster的痛點：
1，不支持multiple/pipline操作（第三方插件也不一定穩(wěn)定）。
2，cluster中每個主節(jié)點要掛一個從節(jié)點，不管這個節(jié)點是不是獨立的物理節(jié)點還是單機多實例中的一個節(jié)點，終究是增加了維護成本。
3，只能使用一個數(shù)據(jù)庫
4，集群自身擴容、縮容帶來的一系列slot遷移等性能問題，以及集群的管理問題
這些所謂的痛點也不復(fù)存在了，所以這里就面臨一個重新選擇的問題：是使用多線程版本的Redis，還是使用Redis cluster？這是一個需要思考的問題。

疑問

關(guān)于redis-benchmark 測試時候 ./bin/redis-benchmark -d 128 -c 200 -n 1000000 -t set -q --threads 2，涉及的兩個參數(shù)-c和--threads，個人是不太理解的
-c的解釋是：指定并發(fā)連接數(shù)
--threads是redis-benchmark的線程數(shù)？
對此去跟老錢（素未謀面，感謝）求證了一下，說該參數(shù)是redis-benchmark客戶端的epoll，服務(wù)器端的多路IO復(fù)用原理已經(jīng)看得我七葷八素了，客戶端也是帶epoll的，還是不太理解這兩者之間的關(guān)系。