單執行緒的Redis一向以簡潔高效著稱，但也有其阿喀琉斯之踵：阻塞！單個執行緒在最容易產生瓶頸的網路讀寫（Redis大key）請求完成之前，其他所有請求都將會被阻塞，嚴重影響其效率，因此Redis的多執行緒呼聲就越來越高，由于是基于記憶體的操作延遲非常低，所以即便是單執行緒模式下CPU資源也不會是的瓶頸，最容易出現瓶頸的還是網路IO操作，在Redis 6.0開始支持多執行緒之后，所謂的多執行緒也只是socket層面的多執行緒，核心的記憶體讀寫還是單執行緒模式，
弄清楚了多執行緒的本質之后，就會有一系列的問題，多執行緒會比單執行緒有多大的提升？設定多少個執行緒合適？見一些大神測驗過，其結果也非常理想，但只是看看也不太過癮，決定一試為快，本文將對Redis的多執行緒進行一個粗淺的測驗驗證，同時需要思考另外一個問題：面對多執行緒版本的Redis，和Redis cluster，該如何選擇？
多執行緒Redis
redis 6.0 的“多執行緒”特性讓很多標題黨高潮連連，參考圖片源自于：美圖技術團隊侵刪，核心的執行緒（Execute Command）還是單執行緒，多執行緒是指網路IO（socket）讀寫的多執行緒化，
如下圖所示，讀寫網路socket中的資料是可以用多個執行緒，所以Redis的多執行緒也叫做io thread，相關引數：“io-threads”，另一個引數是io-threads-do-reads，這里涉及另外一個細節：多執行緒IO主要用在請求完成后回傳結果集的程序，也就是socket寫操作，至于讀socket，單執行緒本身采用的多路IO復用技術，也不會產生瓶頸，因此Redis給出了一個io-threads-do-reads 引數，決定讀socket的時候是否啟用多執行緒，其實io-threads-do-reads是否啟用，對性能的影響并不大，最后會做一個驗證，
測驗策略
本機配置：centos 7，16C+32GB記憶體
Redis版本
下面分別以1執行緒，2執行緒，4執行緒，6執行緒，8執行緒，10執行緒的配置下，200個并發連接進行100百萬次請求，同時為避免網路延遲帶來的影響，redis-benchmark在Redis實體本地，測驗Redis的get和set性能，
翻車
整個測驗開始之前，經歷了兩次翻車才得以繼續 翻車現場1centos 7上默認的gcc是4.*版本，無法編譯Redis 6.0，所以需要升級gcc，因為本機不支持yum安裝，參考這里使用原始碼包安裝，gcc編譯的時候那個酸爽，本機16C+32GB記憶體的環境下，因為缺少某些依賴包，導致失敗了幾次，最終編譯成功的一次，花了大概1個小時10分鐘
翻車現場2沒有認真讀組態檔中的說明，設定io-threads后，重啟Redis服務后，上來就用redis-benchmark直接懟，其結果跟單執行緒差不多，令人大跌眼鏡，
最后還是在原始組態檔發現了這段話：
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設定--threads引數，并且要match Redis中的執行緒設定，--threads引數是redis 6.0后新增的一個引數，只有加上--threads這個引數才能體現出來多執行緒Redis的效率，
關于Thread IO的說明
經歷了第二次翻車之后決定好好看一看redis.conf中關于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.
大概意思如下：大多數情況下redis是以單執行緒的方式運行的，然而，有一些執行緒操作，如斷開鏈接，耗時的I/O操作（bgsave，expired key清理之類的操作）和其他任務是在side執行緒（主執行緒fork出來的子執行緒）中執行的， 現在也可以在不同的I/O執行緒中處理Redis客戶端socket讀和寫，由于寫入（指socket寫入）速度非常慢，Redis用戶通常使用pipelining來提高Redis在單核上的性能，并使用多個實體的方式來擴容，使用I/O執行緒可以很容易地提升Redis在socket讀寫上的性能，而無需求助于管道或實體的分片， Redis 6.0中默認情況下多執行緒被是被禁用的，建議至少有4個或更多核的機器中啟用多執行緒，且至少留下1備用核，使用超過8個執行緒不大可能有太大幫助， 由于Redis實體能夠充分利用CPU資源（譯者注：意思是即便是單執行緒下，CPU并不是瓶頸），多執行緒I/O只有在你確實有性能問題的情況下才能提升運行效率，否則就沒有必要使用這個特性， 如果你有一個4核的服務器，嘗試使用2或3個I/O執行緒，如果是8核，嘗試使用6個執行緒，要啟用多執行緒I/O，請使用以下配置引數：io-threads 4 設定io-threads為1會像傳統的redis一樣啟用單個主執行緒，當I/O threads被啟用之后，僅僅支持寫操作（譯者注：指的是socket的寫操作，socket的讀操作使用多路io復用技術，本身也不是瓶頸）即IO執行緒呼叫syscall并將客戶端緩沖區傳輸到socket，但是，也可以啟用讀寫執行緒，使用以下配置指令進行協議決議，方法是將其設定為“yes”：io-threads-do-reads no 通常情況下，threading reads執行緒對性能的提升幫助并不大 注1：此配置指令不能在運行時通過配置集進行更改，只能在修改組態檔之后重啟，啟用SSL時，當前此特性也無效， 注2：如果你想用Redis-benchmark測驗Redis的性能，務必以threaded mode的方式運行Redis-benchmark，使用--threads選項來匹配Redis執行緒的數量，否則無法觀察到測驗結果的提升，
測驗結果及分析
如下是不同執行緒requests per second測驗結果的橫向對比
因此在本機環境下，io-threads 4設定成2或者4個都ok，最多不超過8個，超出后性能反而會下降，同時也不能超出cpu的個數，正如組態檔中注釋中說的，至少要留出一個CPU， 如下是不同執行緒下10測驗結果中GET和SET的requests per second 平均值對比：
關于io-threads-do-reads引數
上文提到過io-threads-do-reads這個引數，它是決定socket讀操作是否開啟多執行緒，Redis的socket讀操作采用多路IO復用技術，本身不會成為瓶頸，所以這個引數對多執行緒下測驗影響比較小，依舊參考這里的這個圖 侵刪，這個io-threads-do-reads在筆者理解起來，就是socket讀的執行緒，是否開啟影響不大，
參考如下截圖，在開啟了兩個執行緒的情況下，分別開啟和禁用io-threads-do-reads，從整體上看，性能影響差別很小，當然專業的大神可以從原始碼的角度去分析，
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解決的就是擴展性和單節點單執行緒的阻塞隱患，如果Redis支持了多執行緒（目前多執行緒的Redis最對不建議超出8個執行緒），在不考慮單個節點網卡瓶頸的情況下，其實這兩個問題都已經解決了，單節點可以支持多執行緒和充分利用多核CPU，單節點可以支持到25W QPS，還要啥自行車？
同時要考慮到Redis cluster的痛點：
1，不支持multiple操作（第三方插件也不一定穩定），
2，cluster中每個主節點要掛一個從節點，不管這個節點是不是獨立的物理節點還是單機多實體中的一個節點，終究是增加了維護成本，
3，只能使用一個資料庫
4，集群自身擴容、縮容帶來的一系列slot遷移等性能問題，以及集群的管理問題
這些所謂的痛點也不復存在了，所以這里就面臨一個重新選擇的問題：是使用多執行緒版本的Redis，還是使用Redis cluster？這是一個需要思考的問題，
疑問
關于redis-benchmark 測驗時候 ./bin/redis-benchmark -d 128 -c 200 -n 1000000 -t set -q --threads 2，涉及的兩個引數-c和--threads，個人是不太理解的
-c的解釋是：指定并發連接數
--threads是redis-benchmark的執行緒數？
對此去跟老錢（素未謀面，感謝）求證了一下，說該引數是redis-benchmark客戶端的epoll，服務器端的多路IO復用原理已經看得我七葷八素了，客戶端也是帶epoll的，還是不太理解這兩者之間的關系，
redis-benchmark測驗現場
如下是redis-benchmark測驗程序中部分截圖
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/239530.html
標籤：其他
上一篇：MySQL優化索引
下一篇：資料庫三種故障及其恢復手段