這篇文章給大家分享的是有關(guān)redis6.0為什么要引入多線程的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧。

“專業(yè)、務(wù)實(shí)、高效、創(chuàng)新、把客戶的事當(dāng)成自己的事”是我們每一個(gè)人一直以來(lái)堅(jiān)持追求的企業(yè)文化。 創(chuàng)新互聯(lián)是您可以信賴的網(wǎng)站建設(shè)服務(wù)商、專業(yè)的互聯(lián)網(wǎng)服務(wù)提供商! 專注于成都網(wǎng)站建設(shè)、成都做網(wǎng)站、軟件開(kāi)發(fā)、設(shè)計(jì)服務(wù)業(yè)務(wù)。我們始終堅(jiān)持以客戶需求為導(dǎo)向，結(jié)合用戶體驗(yàn)與視覺(jué)傳達(dá)，提供有針對(duì)性的項(xiàng)目解決方案，提供專業(yè)性的建議，創(chuàng)新互聯(lián)建站將不斷地超越自我，追逐市場(chǎng)，引領(lǐng)市場(chǎng)！

Redis6.0之前為什么采用單線程模型

---

嚴(yán)格地說(shuō)，從Redis 4.0之后并不是單線程。除了主線程外，還有一些后臺(tái)線程處理一些較為緩慢的操作，例如無(wú)用連接的釋放、大 key 的刪除等等。

單線程模型，為何性能那么高？

---

Redis作者從設(shè)計(jì)之初，進(jìn)行了多方面的考慮。最終選擇使用單線程模型來(lái)處理命令。之所以選擇單線程模型，主要有如下幾個(gè)重要原因：

1. Redis操作基于內(nèi)存，絕大多數(shù)操作的性能瓶頸不在CPU

2. 單線程模型，避免了線程間切換帶來(lái)的性能開(kāi)銷

3. 使用單線程模型也能并發(fā)的處理客戶端的請(qǐng)求（多路復(fù)用I/O）

4. 使用單線程模型，可維護(hù)性更高，開(kāi)發(fā)，調(diào)試和維護(hù)的成本更低

上述第三個(gè)原因是Redis最終采用單線程模型的決定性因素，其他的兩個(gè)原因都是使用單線程模型額外帶來(lái)的好處，在這里我們會(huì)按順序介紹上述的幾個(gè)原因。

性能瓶頸不在CPU

---

下圖是Redis官網(wǎng)對(duì)單線程模型的說(shuō)明。大概意思是：Redis的瓶頸并不在CPU，它的主要瓶頸在于內(nèi)存和網(wǎng)絡(luò)。在Linux環(huán)境中，Redis每秒甚至可以提交100萬(wàn)次請(qǐng)求。

為什么說(shuō)Redis的瓶頸不在CPU？

首先，Redis絕大部分操作是基于內(nèi)存的，而且是純kv（key-value）操作，所以命令執(zhí)行速度非?？臁Ｎ覀兛梢源蟾爬斫獬?，redis中的數(shù)據(jù)存儲(chǔ)在一張大HashMap中，HashMap的優(yōu)勢(shì)就是查找和寫(xiě)入的時(shí)間復(fù)雜度都是O(1)。Redis內(nèi)部采用這種結(jié)構(gòu)存儲(chǔ)數(shù)據(jù)，就奠定了Redis高性能的基礎(chǔ)。根據(jù)Redis官網(wǎng)描述，在理想情況下Redis每秒可以提交一百萬(wàn)次請(qǐng)求，每次請(qǐng)求提交所需的時(shí)間在納秒的時(shí)間量級(jí)。既然每次的Redis操作都這么快，單線程就可以完全搞定了，那還何必要用多線程呢！

線程上下文切換問(wèn)題

---

另外，多線程場(chǎng)景下會(huì)發(fā)生線程上下文切換。線程是由CPU調(diào)度的，CPU的一個(gè)核在一個(gè)時(shí)間片內(nèi)只能同時(shí)執(zhí)行一個(gè)線程，在CPU由線程A切換到線程B的過(guò)程中會(huì)發(fā)生一系列的操作，主要過(guò)程包括保存線程A的執(zhí)行現(xiàn)場(chǎng)，然后載入線程B的執(zhí)行現(xiàn)場(chǎng)，這個(gè)過(guò)程就是“線程上下文切換”。其中涉及線程相關(guān)指令的保存和恢復(fù)。

頻繁的線程上下文切換可能會(huì)導(dǎo)致性能急劇下降，這會(huì)導(dǎo)致我們不僅沒(méi)有提升處理請(qǐng)求的速度，反而降低了性能，這也是 Redis 對(duì)于多線程技術(shù)持謹(jǐn)慎態(tài)度的原因之一。

在Linux系統(tǒng)中可以使用vmstat命令來(lái)查看上下文切換的次數(shù)，下面是vmstat查看上下文切換次數(shù)的示例：

vmstat 1 表示每秒統(tǒng)計(jì)一次, 其中cs列就是指上下文切換的數(shù)目. 一般情況下, 空閑系統(tǒng)的上下文切換每秒在1500以下。

并行處理客戶端的請(qǐng)求（I/O多路復(fù)用）

---

如上所述：Redis的瓶頸并不在CPU，它的主要瓶頸在于內(nèi)存和網(wǎng)絡(luò)。所謂內(nèi)存瓶頸很好理解，Redis做為緩存使用時(shí)很多場(chǎng)景需要緩存大量數(shù)據(jù)，所以需要大量?jī)?nèi)存空間，這可以通過(guò)集群分片去解決，例如Redis自身的無(wú)中心集群分片方案以及Codis這種基于代理的集群分片方案。

對(duì)于網(wǎng)絡(luò)瓶頸，Redis在網(wǎng)絡(luò)I/O模型上采用了多路復(fù)用技術(shù)，來(lái)減少網(wǎng)絡(luò)瓶頸帶來(lái)的影響。很多場(chǎng)景中使用單線程模型并不意味著程序不能并發(fā)的處理任務(wù)。Redis 雖然使用單線程模型處理用戶的請(qǐng)求，但是它卻使用 I/O 多路復(fù)用技術(shù)“并行”處理來(lái)自客戶端的多個(gè)連接，同時(shí)等待多個(gè)連接發(fā)送的請(qǐng)求。使用 I/O多路復(fù)用技術(shù)能極大地減少系統(tǒng)的開(kāi)銷，系統(tǒng)不再需要為每個(gè)連接創(chuàng)建專門(mén)的監(jiān)聽(tīng)線程，避免了由于大量的線程創(chuàng)建帶來(lái)的巨大性能開(kāi)銷。

下面我們?cè)敿?xì)解釋一下多路復(fù)用I/O模型。為了能更充分理解，我們先了解幾個(gè)基本概念。

Socket（套接字）：Socket可以理解成，在兩個(gè)應(yīng)用程序進(jìn)行網(wǎng)絡(luò)通信時(shí)，分別在兩個(gè)應(yīng)用程序中的通信端點(diǎn)。通信時(shí)，一個(gè)應(yīng)用程序?qū)?shù)據(jù)寫(xiě)入Socket，然后通過(guò)網(wǎng)卡把數(shù)據(jù)發(fā)送到另外一個(gè)應(yīng)用程序的Socket中。我們平常所說(shuō)的HTTP和TCP協(xié)議的遠(yuǎn)程通信，底層都是基于Socket實(shí)現(xiàn)的。5種網(wǎng)絡(luò)IO模型也都要基于Socket實(shí)現(xiàn)網(wǎng)絡(luò)通信。

阻塞與非阻塞：所謂阻塞，就是發(fā)出一個(gè)請(qǐng)求不能立刻返回響應(yīng)，要等所有的邏輯全處理完才能返回響應(yīng)。非阻塞反之，發(fā)出一個(gè)請(qǐng)求立刻返回應(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ū)動(dòng)程序，用戶空間運(yùn)行應(yīng)用程序。Linux以這種方式隔離了操作系統(tǒng)程序和應(yīng)用程序，避免了應(yīng)用程序影響到操作系統(tǒng)自身的穩(wěn)定性。這也是Linux系統(tǒng)超級(jí)穩(wěn)定的主要原因。所有的系統(tǒng)資源操作都在內(nèi)核空間進(jìn)行，比如讀寫(xiě)磁盤(pán)文件，內(nèi)存分配和回收，網(wǎng)絡(luò)接口調(diào)用等。所以在一次網(wǎng)絡(luò)IO讀取過(guò)程中，數(shù)據(jù)并不是直接從網(wǎng)卡讀取到用戶空間中的應(yīng)用程序緩沖區(qū)，而是先從網(wǎng)卡拷貝到內(nèi)核空間緩沖區(qū)，然后再?gòu)膬?nèi)核拷貝到用戶空間中的應(yīng)用程序緩沖區(qū)。對(duì)于網(wǎng)絡(luò)IO寫(xiě)入過(guò)程，過(guò)程則相反，先將數(shù)據(jù)從用戶空間中的應(yīng)用程序緩沖區(qū)拷貝到內(nèi)核緩沖區(qū)，再?gòu)膬?nèi)核緩沖區(qū)把數(shù)據(jù)通過(guò)網(wǎng)卡發(fā)送出去。

多路復(fù)用I/O模型，建立在多路事件分離函數(shù)select，poll，epoll之上。以Redis采用的epoll為例，在發(fā)起read請(qǐng)求前，先更新epoll的socket監(jiān)控列表，然后等待epoll函數(shù)返回（此過(guò)程是阻塞的，所以說(shuō)多路復(fù)用IO本質(zhì)上也是阻塞IO模型）。當(dāng)某個(gè)socket有數(shù)據(jù)到達(dá)時(shí)，epoll函數(shù)返回。此時(shí)用戶線程才正式發(fā)起read請(qǐng)求，讀取并處理數(shù)據(jù)。這種模式用一個(gè)專門(mén)的監(jiān)視線程去檢查多個(gè)socket，如果某個(gè)socket有數(shù)據(jù)到達(dá)就交給工作線程處理。由于等待Socket數(shù)據(jù)到達(dá)過(guò)程非常耗時(shí)，所以這種方式解決了阻塞IO模型一個(gè)Socket連接就需要一個(gè)線程的問(wèn)題，也不存在非阻塞IO模型忙輪詢帶來(lái)的CPU性能損耗的問(wèn)題。多路復(fù)用IO模型的實(shí)際應(yīng)用場(chǎng)景很多，大家耳熟能詳?shù)腞edis，Java NIO，以及Dubbo采用的通信框架Netty都采用了這種模型。

下圖是基于epoll函數(shù)Socket編程的詳細(xì)流程。

可維護(hù)性

---

我們知道，多線程可以充分利用多核CPU，在高并發(fā)場(chǎng)景下，能夠減少因I/O等待帶來(lái)的CPU損耗，帶來(lái)很好的性能表現(xiàn)。不過(guò)多線程卻是一把雙刃劍，帶來(lái)好處的同時(shí)，還會(huì)帶來(lái)代碼維護(hù)困難，線上問(wèn)題難于定位和調(diào)試，死鎖等問(wèn)題。多線程模型中代碼的執(zhí)行過(guò)程不再是串行的，多個(gè)線程同時(shí)訪問(wèn)的共享變量如果處理不當(dāng)也會(huì)帶來(lái)詭異的問(wèn)題。

我們通過(guò)一個(gè)例子，看一下多線程場(chǎng)景下發(fā)生的詭異現(xiàn)象?？聪旅娴拇a：

class MemoryReordering {
  int num = 0;
  boolean flag = false;
  
  public void set() {
    num = 1;     //語(yǔ)句1
    flag = true; //語(yǔ)句2
  }
  
  public int cal() {
    if( flag == true) {    //語(yǔ)句3
      return num + num; //語(yǔ)句4
    }
   
    return -1；
  }
  
}

flag為true時(shí)，cal() 方法返回值是多少？很多人會(huì)說(shuō)：這還用問(wèn)嗎！肯定返回2

結(jié)果可能會(huì)讓你大吃一驚！上面的這段代碼，由于語(yǔ)句1和語(yǔ)句2沒(méi)有數(shù)據(jù)依賴性，可能會(huì)發(fā)生指令重排序，有可能編譯器會(huì)把flag=true放到num=1的前面。此時(shí)set和cal方法分別在不同線程中執(zhí)行，沒(méi)有先后關(guān)系。cal方法，只要flag為true，就會(huì)進(jìn)入if的代碼塊執(zhí)行相加的操作?？赡艿捻樞蚴牵?/p>

• 語(yǔ)句1先于語(yǔ)句2執(zhí)行，這時(shí)的執(zhí)行順序可能是：語(yǔ)句1->語(yǔ)句2->語(yǔ)句3->語(yǔ)句4。執(zhí)行語(yǔ)句4前，num = 1，所以cal的返回值是2

• 語(yǔ)句2先于語(yǔ)句1執(zhí)行，這時(shí)的執(zhí)行順序可能是：語(yǔ)句2->語(yǔ)句3->語(yǔ)句4->語(yǔ)句1。執(zhí)行語(yǔ)句4前，num = 0，所以cal的返回值是0

我們可以看到，在多線程環(huán)境下如果發(fā)生了指令重排序，會(huì)對(duì)結(jié)果造成嚴(yán)重影響。

當(dāng)然可以在第三行處，給flag加上關(guān)鍵字volatile來(lái)避免指令重排。即在flag處加上了內(nèi)存柵欄，來(lái)阻隔flag（柵欄）前后的代碼的重排序。當(dāng)然多線程還會(huì)帶來(lái)可見(jiàn)性問(wèn)題，死鎖問(wèn)題以及共享資源安全等問(wèn)題。

boolean volatile flag = false;

Redis6.0為何引入多線程？

---

Redis6.0引入的多線程部分，實(shí)際上只是用來(lái)處理網(wǎng)絡(luò)數(shù)據(jù)的讀寫(xiě)和協(xié)議解析，執(zhí)行命令仍然是單一工作線程。

從上圖我們可以看到Redis在處理網(wǎng)絡(luò)數(shù)據(jù)時(shí)，調(diào)用epoll的過(guò)程是阻塞的，也就是說(shuō)這個(gè)過(guò)程會(huì)阻塞線程，如果并發(fā)量很高，達(dá)到幾萬(wàn)的QPS，此處可能會(huì)成為瓶頸。一般我們遇到此類網(wǎng)絡(luò)IO瓶頸的問(wèn)題，可以增加線程數(shù)來(lái)解決。開(kāi)啟多線程除了可以減少由于網(wǎng)絡(luò)I/O等待造成的影響，還可以充分利用CPU的多核優(yōu)勢(shì)。Redis6.0也不例外，在此處增加了多線程來(lái)處理網(wǎng)絡(luò)數(shù)據(jù)，以此來(lái)提高Redis的吞吐量。當(dāng)然相關(guān)的命令處理還是單線程運(yùn)行，不存在多線程下并發(fā)訪問(wèn)帶來(lái)的種種問(wèn)題。

性能對(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

多線程版本Redis 6.0，單線程版本是 Redis 5.0.5。多線程版本需要新增以下配置:

io-threads 4 # 開(kāi)啟 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

圖片來(lái)源于網(wǎng)絡(luò)

圖片來(lái)源于網(wǎng)絡(luò)

從上面可以看到 GET/SET 命令在多線程版本中性能相比單線程幾乎翻了一倍。另外，這些數(shù)據(jù)只是為了簡(jiǎn)單驗(yàn)證多線程 I/O 是否真正帶來(lái)性能優(yōu)化，并沒(méi)有針對(duì)具體的場(chǎng)景進(jìn)行壓測(cè)，數(shù)據(jù)僅供參考。本次性能測(cè)試基于 unstble 分支，不排除后續(xù)發(fā)布的正式版本的性能會(huì)更好。

可見(jiàn)單線程有單線程的好處，多線程有多線程的優(yōu)勢(shì)，只有充分理解其中的本質(zhì)原理，才能靈活運(yùn)用于生產(chǎn)實(shí)踐當(dāng)中。

感謝各位的閱讀！關(guān)于Redis6.0為什么要引入多線程就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！

文章標(biāo)題：Redis6.0為什么要引入多線程
文章來(lái)源：http://chinadenli.net/article16/jiicgg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、定制開(kāi)發(fā)、Google、商城網(wǎng)站、小程序開(kāi)發(fā)、網(wǎng)站改版

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)