Redis的自白：我為什么在單線程的這條路上越走越遠(yuǎn)？
我是 Redis，今年 11 歲了~
曾幾何時(shí)我是辣么的單純，辣么的可愛(ài)，而如今我竟背叛了當(dāng)初“誓言”，決心在多線程這條路上義無(wú)反顧的一路狂奔，沒(méi)錯(cuò)我就是你們口中那個(gè)既可愛(ài)又迷人的 Redis，你可以叫我小 R...R 😊。
一波騷操作結(jié)束，我們開始今天的正文。
我們知道在 Redis 4.0 之后就陸陸續(xù)續(xù)添加了一些多線程的功能，難道單線程不香了嗎？
單線程慢嗎？
Redis 的單線程曾幾何時(shí)還是我們炫耀的資本，優(yōu)雅又不失高效的設(shè)計(jì)，讓無(wú)數(shù)的追求者為之著迷。
你要問(wèn)我排第幾？Nginx 是我大哥，NodeJS 是我小弟，我在家中排名老二。
我們兄弟仨可謂單線程的杰出代表，不僅演示了我們的優(yōu)雅更加展現(xiàn)了我們的高效。
有人可能會(huì)問(wèn)：為什么單線程的我，竟然如此囂張？
家中有礦唄，Redis 單線程但性能依舊很快的主要原因有以下幾點(diǎn)：
1. 基于內(nèi)存操作：Redis 的所有數(shù)據(jù)都存在內(nèi)存中，因此所有的運(yùn)算都是內(nèi)存級(jí)別的，所以他的性能比較高；
2. 數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單：Redis 的數(shù)據(jù)結(jié)構(gòu)比較簡(jiǎn)單，是為 Redis 專門設(shè)計(jì)的，而這些簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)的查找和操作的時(shí)間復(fù)雜度都是 O(1)，因此性能比較高；
3. 多路復(fù)用和非阻塞 I/O：Redis 使用 I/O 多路復(fù)用功能來(lái)監(jiān)聽多個(gè) socket 連接客戶端，這樣就可以使用一個(gè)線程連接來(lái)處理多個(gè)請(qǐng)求，減少線程切換帶來(lái)的開銷，同時(shí)也避免了 I/O 阻塞操作，從而大大提高了 Redis 的性能；
4. 避免上下文切換：因?yàn)槭菃尉€程模型，因此就避免了不必要的上下文切換和多線程競(jìng)爭(zhēng)，這就省去了多線程切換帶來(lái)的時(shí)間和性能上的消耗，而且單線程不會(huì)導(dǎo)致死鎖問(wèn)題的發(fā)生。
來(lái)看一下我的父親大大是如何評(píng)價(jià)我的，Redis 的 FAQ（Frequently Asked Questions，常見(jiàn)問(wèn)題）回答了單線程的這個(gè)問(wèn)題，具體內(nèi)容如下：
Redis is single threaded. How can I exploit multiple CPU / cores?
It's not very frequent that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound. For instance, using pipelining Redis running on an average Linux system can deliver even 1 million requests per second, so if your application mainly uses O(N) or O(log(N)) commands, it is hardly going to use too much CPU.
However, to maximize CPU usage you can start multiple instances of Redis in the same box and treat them as different servers. At some point a single box may not be enough anyway, so if you want to use multiple CPUs you can start thinking of some way to shard earlier.
You can find more information about using multiple Redis instances in the Partitioning page.
However with Redis 4.0 we started to make Redis more threaded. For now this is limited to deleting objects in the background, and to blocking commands implemented via Redis modules. For future releases, the plan is to make Redis more and more threaded.
詳見(jiàn)：https://redis.io/topics/faq
他的大體意思是說(shuō) Redis 是基于內(nèi)存操作的，因此他的瓶頸可能是機(jī)器的內(nèi)存或者網(wǎng)絡(luò)帶寬而并非 CPU，既然 CPU 不是瓶頸，那么自然就采用單線程的解決方案了，況且使用多線程比較麻煩。但是在 Redis 4.0 中開始支持多線程了，例如后臺(tái)刪除等功能。
簡(jiǎn)單來(lái)說(shuō)，Redis 4.0 之前一直采用單線程的主要原因有以下三個(gè)：
- 使用單線程模型是 Redis 的開發(fā)和維護(hù)更簡(jiǎn)單，因?yàn)閱尉€程模型方便開發(fā)和調(diào)試；
- 即使使用單線程模型也并發(fā)的處理多客戶端的請(qǐng)求，主要使用的是多路復(fù)用和非阻塞 IO；
- 對(duì)于 Redis 系統(tǒng)來(lái)說(shuō)，主要的性能瓶頸是內(nèi)存或者網(wǎng)絡(luò)帶寬而并非 CPU。
為什么需要多線程？
但是單線程也有單線程的苦惱，比如當(dāng)我（Redis）需要?jiǎng)h除一個(gè)很大的數(shù)據(jù)時(shí)，因?yàn)槭菃尉€程同步操作，這就會(huì)導(dǎo)致 Redis 服務(wù)卡頓，于是在 Redis 4.0 中就新增了多線程的模塊，當(dāng)然此版本中的多線程主要是為了解決刪除數(shù)據(jù)效率比較低的問(wèn)題的，他的相關(guān)指令有以下三個(gè)：
- unlink key
- flushdb async
- flushall async
執(zhí)行示例如下所示：
- > unlink key # 后臺(tái)刪除某個(gè) key
- > OK # 執(zhí)行成功
- > flushall async # 清空所有數(shù)據(jù)
- > OK # 執(zhí)行成功
這樣我就可以把這些壞人“瞬間”拉黑（刪除）了。
所謂的“瞬間”刪除其實(shí)有些夸張，只是從返回的結(jié)果來(lái)看是刪除成功了，但是這只是把刪除工作交給了后臺(tái)的小弟（子線程）異步來(lái)刪除數(shù)據(jù)了。
小貼士：正常情況下使用 del 指令可以很快的刪除數(shù)據(jù)，而當(dāng)被刪除的 key 是一個(gè)非常大的對(duì)象時(shí)，例如時(shí)包含了成千上萬(wàn)個(gè)元素的 hash 集合時(shí)，那么 del 指令就會(huì)造成 Redis 主線程卡頓，因此使用惰性刪除可以有效的避免 Redis 卡頓的問(wèn)題。
Redis 6 中的多線程
之前在 Redis 4.0 中你說(shuō)刪除比較慢，騙我開大（多線程）來(lái)處理也就罷了，為毛 Redis 6.0 還要多線程嘞？
其實(shí)是這樣的在 Redis 4.0 版本中雖然引入了多線程，但此版本中的多線程只能用于大數(shù)據(jù)量的異步刪除，然而對(duì)于非刪除操作的意義并不是很大。
但如果我們使用我們?cè)诜莿h除的環(huán)境下使用多線程的話就可以分?jǐn)?Redis 同步讀寫 I/O 的壓力，以及充分的利用多核 CPU 的資源了，這樣就可以有效的提升 Redis 的 QPS（Query Per Second，每秒查詢率）了。
在 Redis 中雖然使用了 I/O 多路復(fù)用，并且是基于非阻塞 I/O 進(jìn)行操作的，但 I/O 的讀和寫本身是堵塞的，比如當(dāng) socket 中有數(shù)據(jù)時(shí)，Redis 會(huì)通過(guò)調(diào)用先將數(shù)據(jù)從內(nèi)核態(tài)空間拷貝到用戶態(tài)空間，再交給 Redis 調(diào)用，而這個(gè)拷貝的過(guò)程就是阻塞的，當(dāng)數(shù)據(jù)量越大時(shí)拷貝所需要的時(shí)間就越多，而這些操作都是基于單線程完成的。
I/O 多路復(fù)用，簡(jiǎn)單來(lái)說(shuō)就是通過(guò)監(jiān)測(cè)文件的讀寫事件，再通知線程執(zhí)行相關(guān)操作，保證 Redis 的非阻塞 I/O 能夠順利執(zhí)行完成的機(jī)制。
因此在 Redis 6.0 中新增了多線程的功能來(lái)提高 I/O 的讀寫性能，他的主要實(shí)現(xiàn)思路是將主線程的 IO 讀寫任務(wù)拆分給一組獨(dú)立的線程去執(zhí)行，這樣就可以使多個(gè) socket 的讀寫可以并行化了，但 Redis 的命令依舊是由主線程串行執(zhí)行的。
需要注意的是 Redis 6.0 默認(rèn)是禁用多線程的，可以通過(guò)修改 Redis 的配置文件 redis.conf 中的 io-threads-do-reads 等于 true 來(lái)開啟多線程，完整配置為 io-threads-do-reads true，除此之外我們還需要設(shè)置線程的數(shù)量才能正確的開啟多線程的功能，同樣是修改 Redis 的配置，例如設(shè)置 io-threads 4 表示開啟 4 個(gè)線程。
小貼士：關(guān)于線程數(shù)的設(shè)置，官方的建議是如果為 4 核的 CPU，建議線程數(shù)設(shè)置為 2 或 3，如果為 8 核 CPU 建議線程數(shù)設(shè)置為 6，線程數(shù)一定要小于機(jī)器核數(shù)，線程數(shù)并不是越大越好。
關(guān)于 Redis 的性能，我的父王 antirez（Redis 作者）在 RedisConf 2019 分享時(shí)曾提到，Redis 6 引入的多線程 I/O 特性對(duì)性能提升至少是一倍以上。國(guó)內(nèi)也有人在阿里云使用 4 個(gè)線程的 Redis 版本和單線程的 Redis 進(jìn)行比較測(cè)試，發(fā)現(xiàn)測(cè)試的結(jié)果和 antirez 給出的結(jié)論基本吻合，性能基本可以提高一倍。
總結(jié)
Redis 雖然依靠自己的：基于內(nèi)存操作、數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單、多路復(fù)用和非阻塞 I/O、避免了不必要的線程上下文切換等特性，在單線程的環(huán)境下依然很快；但對(duì)于大數(shù)據(jù)的 key 刪除還是卡的飛起，因此在 Redis 4.0 引入了多線程：unlink key/flushall async 等命令，主要用于 Redis 數(shù)據(jù)的刪除，而在 Redis 6.0 中引入了 I/O 多線程的讀寫，這樣就可以更加高效的處理更多的任務(wù)了，Redis 只是將 I/O 讀寫變成了多線程，而命令的執(zhí)行依舊是由主線程串行執(zhí)行的，因此在多線程下操作 Redis 不會(huì)出現(xiàn)線程安全的問(wèn)題。
Redis 無(wú)論是當(dāng)初的單線程設(shè)計(jì)，還是如今與當(dāng)初設(shè)計(jì)相背的多線程，目的只有一個(gè)：讓 Redis 變得越來(lái)越快。
所以 Redis 依舊沒(méi)變，他還是那個(gè)曾經(jīng)的追風(fēng)少年~
