這篇文章給大家分享的是有關(guān)Redis6.0為什么要引入多線程的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個參考。一起跟隨小編過來看看吧。
Redis6.0之前為什么采用單線程模型
嚴(yán)格地說，從Redis 4.0之后并不是單線程。除了主線程外，還有一些后臺線程處理一些較為緩慢的操作，例如無用連接的釋放、大 key 的刪除等等。
單線程模型，為何性能那么高？
Redis作者從設(shè)計(jì)之初，進(jìn)行了多方面的考慮。最終選擇使用單線程模型來處理命令。之所以選擇單線程模型，主要有如下幾個重要原因：
Redis操作基于內(nèi)存，絕大多數(shù)操作的性能瓶頸不在CPU
單線程模型，避免了線程間切換帶來的性能開銷
使用單線程模型也能并發(fā)的處理客戶端的請求（多路復(fù)用I/O）
使用單線程模型，可維護(hù)性更高，開發(fā)，調(diào)試和維護(hù)的成本更低
上述第三個原因是Redis最終采用單線程模型的決定性因素，其他的兩個原因都是使用單線程模型額外帶來的好處，在這里我們會按順序介紹上述的幾個原因。
下圖是Redis官網(wǎng)對單線程模型的說明。大概意思是：Redis的瓶頸并不在CPU，它的主要瓶頸在于內(nèi)存和網(wǎng)絡(luò)。在Linux環(huán)境中，Redis每秒甚至可以提交100萬次請求。
為什么說Redis的瓶頸不在CPU？
首先，Redis絕大部分操作是基于內(nèi)存的，而且是純kv（key-value）操作，所以命令執(zhí)行速度非?？臁Ｎ覀兛梢源蟾爬斫獬?，redis中的數(shù)據(jù)存儲在一張大HashMap中，HashMap的優(yōu)勢就是查找和寫入的時間復(fù)雜度都是O(1)。Redis內(nèi)部采用這種結(jié)構(gòu)存儲數(shù)據(jù)，就奠定了Redis高性能的基礎(chǔ)。根據(jù)Redis官網(wǎng)描述，在理想情況下Redis每秒可以提交一百萬次請求，每次請求提交所需的時間在納秒的時間量級。既然每次的Redis操作都這么快，單線程就可以完全搞定了，那還何必要用多線程呢！
線程上下文切換問題
另外，多線程場景下會發(fā)生線程上下文切換。線程是由CPU調(diào)度的，CPU的一個核在一個時間片內(nèi)只能同時執(zhí)行一個線程，在CPU由線程A切換到線程B的過程中會發(fā)生一系列的操作，主要過程包括保存線程A的執(zhí)行現(xiàn)場，然后載入線程B的執(zhí)行現(xiàn)場，這個過程就是“線程上下文切換”。其中涉及線程相關(guān)指令的保存和恢復(fù)。
頻繁的線程上下文切換可能會導(dǎo)致性能急劇下降，這會導(dǎo)致我們不僅沒有提升處理請求的速度，反而降低了性能，這也是 Redis 對于多線程技術(shù)持謹(jǐn)慎態(tài)度的原因之一。
vmstat 1 表示每秒統(tǒng)計(jì)一次, 其中cs列就是指上下文切換的數(shù)目. 一般情況下, 空閑系統(tǒng)的上下文切換每秒在1500以下。
如上所述：Redis的瓶頸并不在CPU，它的主要瓶頸在于內(nèi)存和網(wǎng)絡(luò)。所謂內(nèi)存瓶頸很好理解，Redis做為緩存使用時很多場景需要緩存大量數(shù)據(jù)，所以需要大量內(nèi)存空間，這可以通過集群分片去解決，例如Redis自身的無中心集群分片方案以及Codis這種基于代理的集群分片方案。
對于網(wǎng)絡(luò)瓶頸，Redis在網(wǎng)絡(luò)I/O模型上采用了多路復(fù)用技術(shù)，來減少網(wǎng)絡(luò)瓶頸帶來的影響。很多場景中使用單線程模型并不意味著程序不能并發(fā)的處理任務(wù)。Redis 雖然使用單線程模型處理用戶的請求，但是它卻使用 I/O 多路復(fù)用技術(shù)“并行”處理來自客戶端的多個連接，同時等待多個連接發(fā)送的請求。使用 I/O多路復(fù)用技術(shù)能極大地減少系統(tǒng)的開銷，系統(tǒng)不再需要為每個連接創(chuàng)建專門的監(jiān)聽線程，避免了由于大量的線程創(chuàng)建帶來的巨大性能開銷。
下面我們詳細(xì)解釋一下多路復(fù)用I/O模型。為了能更充分理解，我們先了解幾個基本概念。
Socket（套接字）：Socket可以理解成，在兩個應(yīng)用程序進(jìn)行網(wǎng)絡(luò)通信時，分別在兩個應(yīng)用程序中的通信端點(diǎn)。通信時，一個應(yīng)用程序?qū)?shù)據(jù)寫入Socket，然后通過網(wǎng)卡把數(shù)據(jù)發(fā)送到另外一個應(yīng)用程序的Socket中。我們平常所說的HTTP和TCP協(xié)議的遠(yuǎn)程通信，底層都是基于Socket實(shí)現(xiàn)的。5種網(wǎng)絡(luò)IO模型也都要基于Socket實(shí)現(xiàn)網(wǎng)絡(luò)通信。
阻塞與非阻塞：所謂阻塞，就是發(fā)出一個請求不能立刻返回響應(yīng)，要等所有的邏輯全處理完才能返回響應(yīng)。非阻塞反之，發(fā)出一個請求立刻返回應(yīng)答，不用等處理完所有邏輯。
內(nèi)核空間與用戶空間：在Linux中，應(yīng)用程序穩(wěn)定性遠(yuǎn)遠(yuǎn)比不上操作系統(tǒng)程序，為了保證操作系統(tǒng)的穩(wěn)定性，Linux區(qū)分了內(nèi)核空間和用戶空間?？梢赃@樣理解，內(nèi)核空間運(yùn)行操作系統(tǒng)程序和驅(qū)動程序，用戶空間運(yùn)行應(yīng)用程序。Linux以這種方式隔離了操作系統(tǒng)程序和應(yīng)用程序，避免了應(yīng)用程序影響到操作系統(tǒng)自身的穩(wěn)定性。這也是Linux系統(tǒng)超級穩(wěn)定的主要原因。所有的系統(tǒng)資源操作都在內(nèi)核空間進(jìn)行，比如讀寫磁盤文件，內(nèi)存分配和回收，網(wǎng)絡(luò)接口調(diào)用等。所以在一次網(wǎng)絡(luò)IO讀取過程中，數(shù)據(jù)并不是直接從網(wǎng)卡讀取到用戶空間中的應(yīng)用程序緩沖區(qū)，而是先從網(wǎng)卡拷貝到內(nèi)核空間緩沖區(qū)，然后再從內(nèi)核拷貝到用戶空間中的應(yīng)用程序緩沖區(qū)。對于網(wǎng)絡(luò)IO寫入過程，過程則相反，先將數(shù)據(jù)從用戶空間中的應(yīng)用程序緩沖區(qū)拷貝到內(nèi)核緩沖區(qū)，再從內(nèi)核緩沖區(qū)把數(shù)據(jù)通過網(wǎng)卡發(fā)送出去。
多路復(fù)用I/O模型，建立在多路事件分離函數(shù)select，poll，epoll之上。以Redis采用的epoll為例，在發(fā)起read請求前，先更新epoll的socket監(jiān)控列表，然后等待epoll函數(shù)返回（此過程是阻塞的，所以說多路復(fù)用IO本質(zhì)上也是阻塞IO模型）。當(dāng)某個socket有數(shù)據(jù)到達(dá)時，epoll函數(shù)返回。此時用戶線程才正式發(fā)起read請求，讀取并處理數(shù)據(jù)。這種模式用一個專門的監(jiān)視線程去檢查多個socket，如果某個socket有數(shù)據(jù)到達(dá)就交給工作線程處理。由于等待Socket數(shù)據(jù)到達(dá)過程非常耗時，所以這種方式解決了阻塞IO模型一個Socket連接就需要一個線程的問題，也不存在非阻塞IO模型忙輪詢帶來的CPU性能損耗的問題。多路復(fù)用IO模型的實(shí)際應(yīng)用場景很多，大家耳熟能詳?shù)腞edis，Java NIO，以及Dubbo采用的通信框架Netty都采用了這種模型。
下圖是基于epoll函數(shù)Socket編程的詳細(xì)流程。
我們知道，多線程可以充分利用多核CPU，在高并發(fā)場景下，能夠減少因I/O等待帶來的CPU損耗，帶來很好的性能表現(xiàn)。不過多線程卻是一把雙刃劍，帶來好處的同時，還會帶來代碼維護(hù)困難，線上問題難于定位和調(diào)試，死鎖等問題。多線程模型中代碼的執(zhí)行過程不再是串行的，多個線程同時訪問的共享變量如果處理不當(dāng)也會帶來詭異的問題。
我們通過一個例子，看一下多線程場景下發(fā)生的詭異現(xiàn)象?？聪旅娴拇a：
重慶分公司
重慶分公司
class MemoryReordering {
int num = 0;
boolean flag = false;
public void set() {
num = 1; //語句1
flag = true; //語句2
}
public int cal() {
if( flag == true) { //語句3
return num + num; //語句4
}
return -1；
}
}flag為true時，cal() 方法返回值是多少？很多人會說：這還用問嗎！肯定返回2
結(jié)果可能會讓你大吃一驚！上面的這段代碼，由于語句1和語句2沒有數(shù)據(jù)依賴性，可能會發(fā)生指令重排序，有可能編譯器會把flag=true放到num=1的前面。此時set和cal方法分別在不同線程中執(zhí)行，沒有先后關(guān)系。cal方法，只要flag為true，就會進(jìn)入if的代碼塊執(zhí)行相加的操作?？赡艿捻樞蚴牵?/p>
語句1先于語句2執(zhí)行，這時的執(zhí)行順序可能是：語句1->語句2->語句3->語句4。執(zhí)行語句4前，num = 1，所以cal的返回值是2
語句2先于語句1執(zhí)行，這時的執(zhí)行順序可能是：語句2->語句3->語句4->語句1。執(zhí)行語句4前，num = 0，所以cal的返回值是0
我們可以看到，在多線程環(huán)境下如果發(fā)生了指令重排序，會對結(jié)果造成嚴(yán)重影響。
當(dāng)然可以在第三行處，給flag加上關(guān)鍵字volatile來避免指令重排。即在flag處加上了內(nèi)存柵欄，來阻隔flag（柵欄）前后的代碼的重排序。當(dāng)然多線程還會帶來可見性問題，死鎖問題以及共享資源安全等問題。
boolean volatile flag = false;
Redis6.0引入的多線程部分，實(shí)際上只是用來處理網(wǎng)絡(luò)數(shù)據(jù)的讀寫和協(xié)議解析，執(zhí)行命令仍然是單一工作線程。
從上圖我們可以看到Redis在處理網(wǎng)絡(luò)數(shù)據(jù)時，調(diào)用epoll的過程是阻塞的，也就是說這個過程會阻塞線程，如果并發(fā)量很高，達(dá)到幾萬的QPS，此處可能會成為瓶頸。一般我們遇到此類網(wǎng)絡(luò)IO瓶頸的問題，可以增加線程數(shù)來解決。開啟多線程除了可以減少由于網(wǎng)絡(luò)I/O等待造成的影響，還可以充分利用CPU的多核優(yōu)勢。Redis6.0也不例外，在此處增加了多線程來處理網(wǎng)絡(luò)數(shù)據(jù)，以此來提高Redis的吞吐量。當(dāng)然相關(guān)的命令處理還是單線程運(yùn)行，不存在多線程下并發(fā)訪問帶來的種種問題。
性能對比
壓測配置:
Redis Server: 阿里云 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 內(nèi)存，主機(jī)型號 ecs.ic5.2xlarge Redis Benchmark Client: 阿里云 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 內(nèi)存，主機(jī)型號 ecs.ic5.2xlarge
多線程版本Redis 6.0，單線程版本是 Redis 5.0.5。多線程版本需要新增以下配置:
io-threads 4 # 開啟 4 個 IO 線程 io-threads-do-reads yes # 請求解析也是用 IO 線程
壓測命令: redis-benchmark -h 192.168.0.49 -a foobared -t set,get -n 1000000 -r 100000000 --threads 4 -d ${datasize} -c 256
圖片來源于網(wǎng)絡(luò) 
圖片來源于網(wǎng)絡(luò)
從上面可以看到 GET/SET 命令在多線程版本中性能相比單線程幾乎翻了一倍。另外，這些數(shù)據(jù)只是為了簡單驗(yàn)證多線程 I/O 是否真正帶來性能優(yōu)化，并沒有針對具體的場景進(jìn)行壓測，數(shù)據(jù)僅供參考。本次性能測試基于 unstble 分支，不排除后續(xù)發(fā)布的正式版本的性能會更好。
可見單線程有單線程的好處，多線程有多線程的優(yōu)勢，只有充分理解其中的本質(zhì)原理，才能靈活運(yùn)用于生產(chǎn)實(shí)踐當(dāng)中。
感謝各位的閱讀！關(guān)于Redis6.0為什么要引入多線程就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
