偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

為什么Redis單線程能達到百萬+QPS?

開發(fā) 后端 Redis
查看了下阿里 Redis 的性能測試報告如下,能夠達到數(shù)十萬、百萬級別的 QPS(暫時忽略阿里對 Redis 所做的優(yōu)化),我們從 Redis 的設(shè)計和實現(xiàn)來分析一下 Redis 是怎么做的。

性能測試報告

查看了下阿里 Redis 的性能測試報告如下,能夠達到數(shù)十萬、百萬級別的 QPS(暫時忽略阿里對 Redis 所做的優(yōu)化),我們從 Redis 的設(shè)計和實現(xiàn)來分析一下 Redis 是怎么做的。

Redis的設(shè)計與實現(xiàn)

其實 Redis 主要是通過三個方面來滿足這樣高效吞吐量的性能需求

  •  高效的數(shù)據(jù)結(jié)構(gòu)
  •  多路復(fù)用 IO 模型
  •  事件機制

1、高效的數(shù)據(jù)結(jié)構(gòu)

Redis 支持的幾種高效的數(shù)據(jù)結(jié)構(gòu) string(字符串)、hash(哈希)、list(列表)、set(集合)、zset(有序集合)

以上幾種對外暴露的數(shù)據(jù)結(jié)構(gòu)它們的底層編碼方式都是做了不同的優(yōu)化的,不細說了,不是本文重點。

2、多路復(fù)用 IO 模型

假設(shè)某一時刻與 Redis 服務(wù)器建立了 1 萬個長連接,對于阻塞式 IO 的做法就是,對每一條連接都建立一個線程來處理,那么就需要 1萬個線程,同時根據(jù)我們的經(jīng)驗對于 IO 密集型的操作我們一般設(shè)置,線程數(shù) = 2 * CPU 數(shù)量 + 1,對于 CPU 密集型的操作一般設(shè)置線程 = CPU 數(shù)量 + 1。

當(dāng)然各種書籍或者網(wǎng)上也有一個詳細的計算公式可以算出更加合適準確的線程數(shù)量,但是得到的結(jié)果往往是一個比較小的值,像阻塞式 IO 這也動則創(chuàng)建成千上萬的線程,系統(tǒng)是無法承載這樣的負荷的更加彈不上高效的吞吐量和服務(wù)了。

而多路復(fù)用 IO 模型的做法是,用一個線程將這一萬個建立成功的鏈接陸續(xù)的放入 event_poll,event_poll 會為這一萬個長連接注冊回調(diào)函數(shù),當(dāng)某一個長連接準備就緒后(建立建立成功、數(shù)據(jù)讀取完成等),就會通過回調(diào)函數(shù)寫入到 event_poll 的就緒隊列 rdlist 中,這樣這個單線程就可以通過讀取 rdlist 獲取到需要的數(shù)據(jù)。為什么 Redis 是單線程,點擊這里看下這篇文章。

另外,大家可以關(guān)注微信公眾號:Java技術(shù)棧,在后臺回復(fù):redis,可以獲取我整理的 N 篇 Redis 教程,都是干貨。

需要注意的是,除了異步 IO 外,其它的 I/O 模型其實都可以歸類為阻塞式 I/O 模型,不同的是像阻塞式 I/O 模型在第一階段讀取數(shù)據(jù)的時候,如果此時數(shù)據(jù)未準備就緒需要阻塞,在第二階段數(shù)據(jù)準備就緒后需要將數(shù)據(jù)從內(nèi)核態(tài)復(fù)制到用戶態(tài)這一步也是阻塞的。而多路復(fù)用 IO 模型在第一階段是不阻塞的,只會在第二階段阻塞。

通過這種方式,就可以用 1 個或者幾個線程來處理大量的連接了,極大的提升了吐吞量

3、事件機制

Redis 客戶端與 Redis 服務(wù)端建立連接,發(fā)送命令,Redis 服務(wù)器響應(yīng)命令都是需要通過事件機制來做的,如下圖   

  • 首先 redis 服務(wù)器運行,監(jiān)聽套接字的 AE_READABLE 事件處于監(jiān)聽的狀態(tài)下,此時連接應(yīng)答處理器工作
  •  客戶端與 Redis 服務(wù)器發(fā)起建立連接,監(jiān)聽套接字產(chǎn)生 AE_READABLE 事件,當(dāng) IO 多路復(fù)用程序監(jiān)聽到其準備就緒后,將該事件壓入隊列中,由文件事件分派器獲取隊列中的事件交于連接應(yīng)答處理器工作處理,應(yīng)答客戶端建立連接成功,同時將客戶端 socket 的 AE_READABLE 事件壓入隊列由文件事件分派器獲取隊列中的事件交命令請求處理器關(guān)聯(lián)
  • 客戶端發(fā)送 set key value 請求,客戶端 socket 的 AE_READABLE 事件,當(dāng) IO 多路復(fù)用程序監(jiān)聽到其準備就緒后,將該事件壓入隊列中,由文件事件分派器獲取隊列中的事件交于命令請求處理器關(guān)聯(lián)處理
  • 命令請求處理器關(guān)聯(lián)處理完成后,需要響應(yīng)客戶端操作完成,此時將產(chǎn)生 socket 的 AE_WRITEABLE 事件壓入隊列,由文件事件分派器獲取隊列中的事件交于命令恢復(fù)處理器處理,返回操作結(jié)果,完成后將解除 AE_WRITEABLE 事件與命令恢復(fù)處理器的關(guān)聯(lián)

reactor模式

大體上可以說 Redis 的工作模式是,reactor 模式配合一個隊列,用一個 serverAccept 線程來處理建立請求的鏈接,并且通過 IO 多路復(fù)用模型,讓內(nèi)核來監(jiān)聽這些 socket,一旦某些 socket 的讀寫事件準備就緒后就對應(yīng)的事件壓入隊列中,然后 worker 工作,由文件事件分派器從中獲取事件交于對應(yīng)的處理器去執(zhí)行,當(dāng)某個事件執(zhí)行完成后文件事件分派器才會從隊列中獲取下一個事件進行處理。

可以類比在 netty 中,我們一般會設(shè)置 bossGroup 和 workerGroup 默認情況下 bossGroup 為 1,workerGroup = 2 * cpu 數(shù)量,這樣可以由多個線程來處理讀寫就緒的事件,但是其中不能有比較耗時的操作如果有的話需要將其放入線程池中,不然會降低其吐吞量。在 Redis 中我們可以看做這二者的值都是 1。

為什么說存儲的值不宜過大

比如一個 string key = a,存儲了 500MB,首先讀取事件壓入隊列中,文件事件分派器從中獲取到后,交于命令請求處理器處理,此處就涉及到從磁盤中加載 500MB。

比如是普通的 SSD 硬盤,讀取速度 200MB/S,那么需要 2.5S 的讀取時間,在內(nèi)存中讀取數(shù)據(jù)比較快比如 DDR4 中 50G/秒,讀取 500MB 需要 100 毫秒左右。

線程的庫一般默認 10 毫秒就算慢查詢了,大部分的指令執(zhí)行時間都是微秒級別,此時其它 socket 所有的請求都將處于等待過程中,就會導(dǎo)致阻塞了 100 毫秒,同時又會占用較大的帶寬導(dǎo)致吞吐量進一步下降。 

 

責(zé)任編輯:龐桂玉 來源: Java技術(shù)棧
相關(guān)推薦

2021-03-03 08:01:58

Redis多線程程序

2023-10-15 12:23:10

單線程Redis

2020-10-30 16:20:38

Redis單線程高并發(fā)

2023-03-21 08:02:36

Redis6.0IO多線程

2019-06-17 14:20:51

Redis數(shù)據(jù)庫Java

2025-01-17 08:23:33

2023-08-17 14:12:17

2019-05-06 11:12:18

Redis高并發(fā)單線程

2019-05-07 09:44:45

Redis高并發(fā)模型

2020-11-17 10:20:53

Redis多線程單線程

2025-06-17 00:22:00

2019-02-18 08:10:53

2022-01-04 11:11:32

Redis單線程Reactor

2020-10-16 16:00:50

Redis單線程數(shù)據(jù)庫

2021-12-28 09:50:18

Redis單線程高并發(fā)

2025-04-24 08:15:00

Redis單線程線程

2009-07-10 09:05:20

SwingWorker

2019-11-25 10:13:52

Redis單線程I

2024-09-27 11:51:33

Redis多線程單線程

2019-04-02 11:20:48

Redis高并發(fā)單線程
點贊
收藏

51CTO技術(shù)棧公眾號