2019年的 RedisConf 比以往時(shí)候來的更早一些，今年會(huì)議時(shí)間是4月1-3號(hào)，仍然是在舊金山魚人碼頭Pier 27。恰逢今年是 Redis 第10周年，規(guī)模也比以往大一些，注冊(cè)人數(shù)超過1600人，總共有80個(gè)議題，除了RedisLabs外還有很多云廠商和Redis用戶帶來分享。Redis 作者 antirez 在 RedisConf 2019 做了分享，其中一段展示了 Redis 6 引入的多線程 IO 特性對(duì)性能提升至少是一倍以上。

無獨(dú)有偶，在之前 antirez 的博客上，我們已經(jīng)提前知道了這個(gè)消息：

多線程實(shí)現(xiàn)

目前對(duì)于單線程 Redis 來說，性能瓶頸主要在于網(wǎng)絡(luò)的 IO 消耗, 優(yōu)化主要有兩個(gè)方向:

提高網(wǎng)絡(luò) IO 性能，典型的實(shí)現(xiàn)像使用 DPDK 來替代內(nèi)核網(wǎng)絡(luò)棧的方式

使用多線程充分利用多核，典型的實(shí)現(xiàn)像 Memcached

多線程特性在社區(qū)也被反復(fù)提了很久后，Redis作者antirez終于在 Redis 6 加入多線程。

因?yàn)樽x寫網(wǎng)絡(luò)的read/write系統(tǒng)調(diào)用在Redis執(zhí)行期間占用了大部分CPU時(shí)間，如果把網(wǎng)絡(luò)讀寫做成多線程的方式對(duì)性能會(huì)有很大提升。現(xiàn)在已經(jīng)實(shí)現(xiàn)了第一版，write side即回復(fù)客戶端這部分已經(jīng)完成了，并且去掉了主線程和IO線程之間的互斥鎖，采用busy loop的形式來等待io線程工作結(jié)束，這部分能夠有50%的性能提升，架構(gòu)圖如下：

Redis 的多線程部分只是用來處理網(wǎng)絡(luò)數(shù)據(jù)的讀寫和協(xié)議解析，執(zhí)行命令仍然是單線程。之所以這么設(shè)計(jì)是不想 Redis 因?yàn)槎嗑€程而變得復(fù)雜，需要去控制 key、lua、事務(wù)，LPUSH/LPOP 等等的并發(fā)問題。

多線程 IO 的讀(請(qǐng)求)和寫(響應(yīng))在實(shí)現(xiàn)流程是一樣的，只是執(zhí)行讀還是寫操作的差異。同時(shí)這些 IO 線程在同一時(shí)刻全部是讀或者寫，不會(huì)部分讀或部分寫的情況，所以下面以讀流程作為例子。分析過程中只會(huì)覆蓋核心邏輯而不是全部細(xì)節(jié)。如果想完全理解細(xì)節(jié)，建議看完之后再次看一次源碼實(shí)現(xiàn)。

加入多線程 IO 之后，整體的讀流程如下:

主線程負(fù)責(zé)接收建連請(qǐng)求，讀事件到來(收到請(qǐng)求)則放到一個(gè)全局等待讀處理隊(duì)列

主線程處理完讀事件之后，通過 RR(Round Robin) 將這些連接分配給這些 IO 線程，然后主線程忙等待(spinlock 的效果)狀態(tài)

IO 線程將請(qǐng)求數(shù)據(jù)讀取并解析完成(這里只是讀數(shù)據(jù)和解析并不執(zhí)行)

主線程執(zhí)行所有命令并清空整個(gè)請(qǐng)求等待讀處理隊(duì)列(執(zhí)行部分串行)

上面的這個(gè)過程是完全無鎖的，因?yàn)樵?IO 線程處理的時(shí)主線程會(huì)等待全部的 IO 線程完成，所以不會(huì)出現(xiàn)data race的場(chǎng)景。

性能對(duì)比

壓測(cè)配置：

Redis Server: 阿里云 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 內(nèi)存，主機(jī)型號(hào) ecs.ic5.2xlarge
Redis Benchmark Client: 阿里云 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 內(nèi)存，主機(jī)型號(hào) ecs.ic5.2xlarge

多線程 IO 版本剛合并到 unstable 分支一段時(shí)間，所以只能使用 unstable 分支來測(cè)試多線程 IO，單線程版本是 Redis 5.0.5。多線程 IO 版本需要新增以下配置:

io-threads 4 # 開啟 4 個(gè) IO 線程
io-threads-do-reads yes # 請(qǐng)求解析也是用 IO 線程

壓測(cè)命令:

redis-benchmark -h 192.168.0.49 -a foobared -t set,get -n 1000000 -r 100000000 --threads 4 -d ${datasize} -c 256

從上面可以看到 GET/SET 命令在 4 線程 IO 時(shí)性能相比單線程是幾乎是翻倍了。另外，這些數(shù)據(jù)只是為了簡(jiǎn)單驗(yàn)證多線程 IO 是否真正帶來性能優(yōu)化，并沒有針對(duì)嚴(yán)謹(jǐn)?shù)难訒r(shí)控制和不同并發(fā)的場(chǎng)景進(jìn)行壓測(cè)。數(shù)據(jù)僅供驗(yàn)證參考而不能作為線上指標(biāo)，且只是目前的 unstble分支的性能，不排除后續(xù)發(fā)布的正式版本的性能會(huì)更好。

總結(jié)

Redis 6.0 預(yù)計(jì)會(huì)在 2019 年底發(fā)布，將在性能、協(xié)議以及權(quán)限控制都會(huì)有很大的改進(jìn)。antirez 今年全身心投入在優(yōu)化 Redis 和集群的功能，特別值得期待。另外，今年年底社區(qū)也會(huì)同時(shí)發(fā)布第一個(gè)版本 redis cluster proxy 來解決多語言 SDK 兼容的問題，期待在具備 proxy 功能之后 cluster 能在國(guó)內(nèi)有更加廣泛的應(yīng)用。

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的redis 多线程_Java架构师Redis单线程？别逗了，Redis6.0多线程重磅来袭的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。