周末被一位小同學憋的很窩火。他要和我探討一下，redis到底是多線程的還是單線程的。這個問題本來比較好解釋，但我遇到的卻是一個杠精。

答案是顯而易見的：redis6，逃不過真香定理，引入了多線程；而在redis6之前，卻是單線程的。

也就是說，這不是一個是和否的問題，還涉及到第二維度的版本參與。

可是，這位同學要打我的臉。不知道小姐姐的臉皮很嫩么？摸不得。

“照你的邏輯，redis5是單線程的了？”

“是的。”

“那下面這張截圖是怎么回事？”

同學甩給我一張圖，并送來一個鄙視的眼神。

“使用top -Hp 查看。redis5有4個線程。該怎么解釋？”

這個問題，我也不知道怎么跟他解釋。使用top命令去觀測，redis5肯定是多線程的，比如bgsave，aof等，肯定要開啟一個線程去操作，否則早就炸了。

按照這個邏輯去說，redis就從來沒有單進程過。看著這張圖，我陷入了無盡的憂愁。

“Redis是否是單進程，主要是針對Redis的讀寫操作來說的”。但這句話對于杠精并沒有什么信服力。

“寫程序要嚴謹，你們這些人都太不嚴謹了。多線程就是多線程，你應(yīng)該問'redis的讀寫操作到底是不是多線程的'”。

我問你個大頭鬼。我并不想再和他交流，因為我為自己的博學感到無地自容。

但他接下來的一個問題，卻讓我陷入了真正的沉思。

1. redis的多線程有多快？

redis的多線程到底有什么性能提升呢？

官方的說法是：possible to easily speedup two times。可能會比較容易的提升到兩倍速度。

我英文不太好，對這種英文的修飾感到很迷惑。既然easily了，為什么還有possible。two times，到底是提升了2倍，還是提升到2倍。

官方說，到底能夠提升多少，還要看硬件的能力。

官方推薦，只有你的CPU核數(shù)，達到4個的時候，才有必要試一試這個多線程的Feature。

不要用土豪的眼睛盯著我，這種4core的配置，已經(jīng)打死了大多數(shù)公司了。所以Redis貼心的把多線程功能是關(guān)閉的。（好像有點語病）

我只能求助那些在一線的前同事們。他們有沒有在生產(chǎn)環(huán)境，用上這劃時代的多線程Redis6x呢？

結(jié)果很令我滿意，沒有！

其中有一個回復(fù)我特別滿意。他說：“你竟然在問一個停留在JDK1.6的我，跑著Windows版本Redis的我，是否用到了Redis6。我還在用著Redis3呢。”

另外一個回復(fù)我感到更滿意，他說：“滾！”

2. 怎么用?

新技術(shù)肯定是要吹捧一下的，否則沒人實踐踩坑，作為追隨者就只能吃翔。

多線程在理論上，肯定是會有性能提升的。一個爸爸賺錢和2個爸爸賺錢，效果自然不一樣，只是苦了媽媽了。

Redis6的多線程開啟，需要配置一個參數(shù)。 

io-threads 4 

當開啟之后，只有出流量使用多線程，如果你想要入流量也走多線程，那也可以配置以下參數(shù)。 

io-threads-do-reads yes 

就這么兩個參數(shù)，可以看到現(xiàn)在的redis多線程，還是稍顯寒磣了一些。

我們把它開啟之后，仍然使用top -Hp 查看相關(guān)進程，可以看到多了3個io_thd進程。

這部分邏輯，是在networking.c種實現(xiàn)的。這個文件已經(jīng)達到了3k多行，也是夠龐大的了。

3. Redis為什么又搞多線程了

使用redis-benchmark測試，單機單核的吞吐量，能夠達到10w+。

1秒是1000000000納秒，單次內(nèi)存操作大約是100納秒左右，那內(nèi)存操作可以達到1000w/s的速度。那Redis的瓶頸在哪里呢？

使用perf進行追蹤，可以發(fā)現(xiàn)它的耗時，主要是體現(xiàn)在sys_write系統(tǒng)調(diào)用上，也就是向socket寫數(shù)據(jù)。

既然瓶頸找到了，那就把它優(yōu)化掉。redis選擇的方式是使用多線程。

我使用benchmark測試了一下，4core的機器，CPU跑滿的時候，QPS達到了16w，并沒有翻倍（相對于單核的9w/s）。 

benchmark 6379 clients 32  
164519.20 requests per second  
165411.09 requests per second 

用這么強的硬件，獲得這樣有限的性能提升，差強人意。

這就不難解釋為什么現(xiàn)在實踐的人那么少。出了因為新，還是不夠吸引人。

畢竟，4core的機器，我部署上3臺redis cluster的實例，理論上會提升三倍呢。

redis配置文件里，有不少內(nèi)容在注釋這個新特性。

4. 怎么實現(xiàn)？

如圖，一次redis請求，要建立連接，然后獲取操作的命令，然后執(zhí)行命令，最后將響應(yīng)的結(jié)果寫到socket上。

在redis的多線程模式下，獲取、解析命令，以及輸出結(jié)果著兩個過程，可以配置成多線程執(zhí)行的，因為它畢竟是我們定位到的主要耗時點。

但命令的執(zhí)行，也就是內(nèi)存操作，依然是單線程運行的。

這種設(shè)計造成了一個特性。

redis現(xiàn)在依然沒有多線程的鎖競爭和線程安全問題，因為它的數(shù)據(jù)讀取這一步驟，仍然是單線程的，要排隊運行。一些耗時的操作，比如keys *，hgetall等，仍然要注意。

redis并不是傳統(tǒng)的reactor模型，說實話很多東西硬套概念的話肯定只能鉆進個頭去漏出個尾巴。它也并不是master，worker這種干干凈凈的類似于memcached的模型，因為它把命令執(zhí)行操作給抽取出來了。其中緣由，看上面這張圖就夠了。

End

那么，下一個吸引杠精的問題難題來了：在這種多線程應(yīng)用場景下，redis算是I/O密集型，還是計算密集型呢？

或許，如果redis多線程中，無處不在的輪詢，屬于“計算”的話，它算是一個計算密集型應(yīng)用吧。