1、redis為什么選擇單線程

1.1、redis7單線程

Redis是單線程

主要是指Redis的網(wǎng)絡(luò)IO和鍵值對(duì)讀寫(xiě)是由一個(gè)線程來(lái)完成的

Redis在處理客戶端的請(qǐng)求時(shí)包括獲取 (socket 讀)、解析、執(zhí)行、內(nèi)容返回 (socket 寫(xiě)) 等都由一個(gè)順序串行的主線程處理，這就是所謂的“單線程”。

這也是Redis對(duì)外提供鍵值存儲(chǔ)服務(wù)的主要流程。

但Redis的其他功能，比如持久化RDB、AOF、異步刪除、集群數(shù)據(jù)同步等等，其實(shí)是由額外的線程執(zhí)行的。

Redis命令工作線程是單線程的，但是，整個(gè)Redis來(lái)說(shuō)，是多線程的;

1.2、redis7單線程快

基于內(nèi)存操作：redis的所有數(shù)據(jù)都存在內(nèi)存中，因此所有的運(yùn)算都是內(nèi)存級(jí)別的，性能比較高

數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單：redis的數(shù)據(jù)結(jié)構(gòu)是專門設(shè)計(jì)的，而這些簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)的查找和操作的時(shí)間大部分復(fù)雜度都是O(1)

多路復(fù)用和非阻塞I/O：redis使用I/O多路復(fù)用功能來(lái)監(jiān)聽(tīng)多個(gè)socket連接客戶端，這樣就可以使用一個(gè)線程來(lái)處理多個(gè)請(qǐng)求，減少線程切換帶來(lái)的開(kāi)銷。同時(shí)也避免了I/O阻塞操作

避免上下文切換：因?yàn)槭菃尉€程模型，因此就避免了不必要的上下文切換和多線程競(jìng)爭(zhēng)，省去了多線程切換帶來(lái)的時(shí)間和性能上的消耗，而且單線程不會(huì)導(dǎo)致死鎖問(wèn)題的發(fā)生

簡(jiǎn)單來(lái)說(shuō)，Redis4.0之前一直采用單線程的主要原因有以下三個(gè)：

1 使用單線程模型是 Redis 的開(kāi)發(fā)和維護(hù)更簡(jiǎn)單，因?yàn)閱尉€程模型方便開(kāi)發(fā)和調(diào)試;

2 即使使用單線程模型也并發(fā)的處理多客戶端的請(qǐng)求，主要使用的是IO多路復(fù)用和非阻塞IO;

3 對(duì)于Redis系統(tǒng)來(lái)說(shuō)，主要的性能瓶頸是內(nèi)存或者網(wǎng)絡(luò)帶寬而并非 CPU。

2、為啥加入多線程

1、單線程的問(wèn)題

正常情況下使用 del 指令可以很快的刪除數(shù)據(jù)

而當(dāng)被刪除的 key 是一個(gè)非常大的對(duì)象時(shí)，例如時(shí)包含了成千上萬(wàn)個(gè)元素的 hash 集合時(shí)，那么 del 指令就會(huì)造成 Redis 主線程卡頓。

這就是redis3.x單線程時(shí)代最經(jīng)典的故障，大key刪除的頭疼問(wèn)題，

由于redis是單線程的，del bigKey .....

等待很久這個(gè)線程才會(huì)釋放，類似加了一個(gè)synchronized鎖，你可以想象高并發(fā)下，程序堵成什么樣子?

2、解決辦法

使用惰性刪除可以有效的避免redis卡頓的問(wèn)題

比如當(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)題的。

unlink key

flushdb async

flushall async

把刪除工作交給了后臺(tái)的小弟(子線程)異步來(lái)刪除數(shù)據(jù)了。

因?yàn)镽edis是單個(gè)主線程處理，redis之父antirez一直強(qiáng)調(diào)"Lazy Redis is better Redis".

而lazy free的本質(zhì)就是把某些cost(主要時(shí)間復(fù)制度，占用主線程cpu時(shí)間片)較高刪除操作，

從redis主線程剝離讓bio子線程來(lái)處理，極大地減少主線阻塞時(shí)間。從而減少刪除導(dǎo)致性能和穩(wěn)定性問(wèn)題。

在redis4.0就引入了多個(gè)線程來(lái)實(shí)現(xiàn)數(shù)據(jù)的異步惰性刪除等功能

但是其處理讀寫(xiě)請(qǐng)求的仍然只有一個(gè)線程，所以仍然算是狹義上的單線程

3、redis6/7多線程特性和IO多路復(fù)用

3.1、redis主要的性能瓶頸是內(nèi)存或者網(wǎng)絡(luò)帶寬而非CPU

3.2、redis6/7真正多線程登場(chǎng)

在Redis6/7中，非常受關(guān)注的第一個(gè)新特性就是多線程。

這是因?yàn)椋琑edis一直被大家熟知的就是它的單線程架構(gòu)，雖然有些命令操作可以用后臺(tái)線程或子進(jìn)程執(zhí)行(比如數(shù)據(jù)刪除、快照生成、AOF重寫(xiě))。

但是，從網(wǎng)絡(luò)IO處理到實(shí)際的讀寫(xiě)命令處理，都是由單個(gè)線程完成的。

隨著網(wǎng)絡(luò)硬件的性能提升，Redis的性能瓶頸有時(shí)會(huì)出現(xiàn)在網(wǎng)絡(luò)IO的處理上，也就是說(shuō)，單個(gè)主線程處理網(wǎng)絡(luò)請(qǐng)求的速度跟不上底層網(wǎng)絡(luò)硬件的速度,

為了應(yīng)對(duì)這個(gè)問(wèn)題:

采用多個(gè)IO線程來(lái)處理網(wǎng)絡(luò)請(qǐng)求，提高網(wǎng)絡(luò)請(qǐng)求處理的并行度，Redis6/7就是采用的這種方法。

但是，Redis的多IO線程只是用來(lái)處理網(wǎng)絡(luò)請(qǐng)求的，對(duì)于讀寫(xiě)操作命令Redis仍然使用單線程來(lái)處理。

這是因?yàn)椋琑edis處理請(qǐng)求時(shí)，網(wǎng)絡(luò)處理經(jīng)常是瓶頸，通過(guò)多個(gè)IO線程并行處理網(wǎng)絡(luò)操作，可以提升實(shí)例的整體處理性能。

而繼續(xù)使用單線程執(zhí)行命令操作，就不用為了保證Lua腳本、事務(wù)的原子性，額外開(kāi)發(fā)多線程互斥加鎖機(jī)制了(不管加鎖操作處理)，這樣一來(lái)，Redis線程模型實(shí)現(xiàn)就簡(jiǎn)單了

3.3、主線程和IO線程是協(xié)作完成請(qǐng)求處理

3.4、Unix網(wǎng)絡(luò)編程中的五種IO模型

Blocking IO 阻塞IO

NoneBlocking IO 非阻塞IO

IO Multiplexing IO多路復(fù)用

signal driven IO 信號(hào)驅(qū)動(dòng)IO

asynchronous IO 異步IO

IO多路復(fù)用

一個(gè)服務(wù)端進(jìn)程可以同時(shí)處理多個(gè)套接字描述符

實(shí)現(xiàn)IO多路復(fù)用的模型有3種：select-->poll-->epoll三個(gè)階段來(lái)描述

模擬一個(gè)tcp服務(wù)器處理30個(gè)客戶socket。

假設(shè)你是一個(gè)監(jiān)考老師，讓30個(gè)學(xué)生解答一道競(jìng)賽考題，然后負(fù)責(zé)驗(yàn)收學(xué)生答卷，你有下面幾個(gè)選擇：

第一種選擇(輪詢)：按順序逐個(gè)驗(yàn)收，先驗(yàn)收A，然后是B，之后是C、D。。。這中間如果有一個(gè)學(xué)生卡住，全班都會(huì)被耽誤,你用循環(huán)挨個(gè)處理socket，根本不具有并發(fā)能力。

第二種選擇(來(lái)一個(gè)new一個(gè)，1對(duì)1服務(wù))：你創(chuàng)建30個(gè)分身線程，每個(gè)分身線程檢查一個(gè)學(xué)生的答案是否正確。這種類似于為每一個(gè)用戶創(chuàng)建一個(gè)進(jìn)程或者線程處理連接。

第三種選擇(響應(yīng)式處理，1對(duì)多服務(wù))，你站在講臺(tái)上等，誰(shuí)解答完誰(shuí)舉手。這時(shí)C、D舉手，表示他們解答問(wèn)題完畢，你下去依次檢查C、D的答案，然后繼續(xù)回到講臺(tái)上等。

此時(shí)E、A又舉手，然后去處理E和A。。。

這種就是IO復(fù)用模型。Linux下的select、poll和epoll就是干這個(gè)的。

將用戶socket對(duì)應(yīng)的文件描述符(FileDescriptor)注冊(cè)進(jìn)epoll，然后epoll幫你監(jiān)聽(tīng)哪些socket上有消息到達(dá)，這樣就避免了大量的無(wú)用操作。

此時(shí)的socket應(yīng)該采用非阻塞模式。這樣，整個(gè)過(guò)程只在調(diào)用select、poll、epoll這些調(diào)用的時(shí)候才會(huì)阻塞，

收發(fā)客戶消息是不會(huì)阻塞的，整個(gè)進(jìn)程或者線程就被充分利用起來(lái)，這就是事件驅(qū)動(dòng)，所謂的reactor反應(yīng)模式。

在單個(gè)線程通過(guò)記錄跟蹤每一個(gè)Sockek(I/O流)的狀態(tài)來(lái)同時(shí)管理多個(gè)I/O流. 一個(gè)服務(wù)端進(jìn)程可以同時(shí)處理多個(gè)套接字描述符。

目的是盡量多的提高服務(wù)器的吞吐能力。

大家都用過(guò)nginx，nginx使用epoll接收請(qǐng)求，ngnix會(huì)有很多鏈接進(jìn)來(lái)， epoll會(huì)把他們都監(jiān)視起來(lái)，然后像撥開(kāi)關(guān)一樣，誰(shuí)有數(shù)據(jù)就撥向誰(shuí)，然后調(diào)用相應(yīng)的代碼處理。

redis類似同理，這就是IO多路復(fù)用原理，有請(qǐng)求就響應(yīng)，沒(méi)請(qǐng)求不打擾。

3.5、簡(jiǎn)單說(shuō)明

redis工作線程是單線程的

但是整個(gè)redis來(lái)說(shuō)，是多線程的

4、redis7如何開(kāi)啟多線程

1.設(shè)置io-thread-do-reads配置項(xiàng)為yes，表示啟動(dòng)多線程。

2。設(shè)置線程個(gè)數(shù)。

關(guān)于線程數(shù)的設(shè)置，官方的建議是如果為 4 核的 CPU，建議線程數(shù)設(shè)置為 2 或 3，如果為 8 核 CPU 建議線程數(shù)設(shè)置為 6，線程數(shù)一定要小于機(jī)器核數(shù)，線程數(shù)并不是越大越好。

5、總結(jié)

Redis自身出道就是優(yōu)秀，基于內(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ù)的異步刪除;

而在 Redis6/7中引入了 I/O 多線程的讀寫(xiě)，這樣就可以更加高效的處理更多的任務(wù)了，Redis 只是將 I/O 讀寫(xiě)變成了多線程

而命令的執(zhí)行依舊是由主線程串行執(zhí)行的，因此在多線程下操作 Redis 不會(huì)出現(xiàn)線程安全的問(wèn)題。

Redis 無(wú)論是當(dāng)初的單線程設(shè)計(jì)，還是如今與當(dāng)初設(shè)計(jì)相背的多線程，目的只有一個(gè)：讓 Redis 變得越來(lái)越快。

審核編輯：湯梓紅