這篇文章主要介紹“redis的設(shè)計(jì)與實(shí)現(xiàn)方法是什么”，在日常操作中，相信很多人在Redis的設(shè)計(jì)與實(shí)現(xiàn)方法是什么問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Redis的設(shè)計(jì)與實(shí)現(xiàn)方法是什么”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！
10年積累的網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有盧氏免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
Redis的設(shè)計(jì)與實(shí)現(xiàn)
其實(shí) Redis 主要是通過(guò)三個(gè)方面來(lái)滿足這樣高效吞吐量的性能需求1、高效的數(shù)據(jù)結(jié)構(gòu)
Redis 支持的幾種高效的數(shù)據(jù)結(jié)構(gòu) string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）以上幾種對(duì)外暴露的數(shù)據(jù)結(jié)構(gòu)它們的底層編碼方式都是做了不同的優(yōu)化的，不細(xì)說(shuō)了，不是本文重點(diǎn)。2、多路復(fù)用 IO 模型
假設(shè)某一時(shí)刻與 Redis 服務(wù)器建立了 1 萬(wàn)個(gè)長(zhǎng)連接，對(duì)于阻塞式 IO 的做法就是，對(duì)每一條連接都建立一個(gè)線程來(lái)處理，那么就需要 1萬(wàn)個(gè)線程，同時(shí)根據(jù)我們的經(jīng)驗(yàn)對(duì)于 IO 密集型的操作我們一般設(shè)置，線程數(shù) = 2 * CPU 數(shù)量 + 1，對(duì)于 CPU 密集型的操作一般設(shè)置線程 = CPU 數(shù)量 + 1。當(dāng)然各種書(shū)籍或者網(wǎng)上也有一個(gè)詳細(xì)的計(jì)算公式可以算出更加合適準(zhǔn)確的線程數(shù)量，但是得到的結(jié)果往往是一個(gè)比較小的值，像阻塞式 IO 這也動(dòng)則創(chuàng)建成千上萬(wàn)的線程，系統(tǒng)是無(wú)法承載這樣的負(fù)荷的更加彈不上高效的吞吐量和服務(wù)了。而多路復(fù)用 IO 模型的做法是，用一個(gè)線程將這一萬(wàn)個(gè)建立成功的鏈接陸續(xù)的放入 event_poll，event_poll 會(huì)為這一萬(wàn)個(gè)長(zhǎng)連接注冊(cè)回調(diào)函數(shù)，當(dāng)某一個(gè)長(zhǎng)連接準(zhǔn)備就緒后（建立建立成功、數(shù)據(jù)讀取完成等），就會(huì)通過(guò)回調(diào)函數(shù)寫(xiě)入到 event_poll 的就緒隊(duì)列 rdlist 中，這樣這個(gè)單線程就可以通過(guò)讀取 rdlist 獲取到需要的數(shù)據(jù)。需要注意的是，除了異步 IO 外，其它的 I/O 模型其實(shí)都可以歸類為阻塞式 I/O 模型，不同的是像阻塞式 I/O 模型在第一階段讀取數(shù)據(jù)的時(shí)候，如果此時(shí)數(shù)據(jù)未準(zhǔn)備就緒需要阻塞，在第二階段數(shù)據(jù)準(zhǔn)備就緒后需要將數(shù)據(jù)從內(nèi)核態(tài)復(fù)制到用戶態(tài)這一步也是阻塞的。而多路復(fù)用 IO 模型在第一階段是不阻塞的，只會(huì)在第二階段阻塞。
通過(guò)這種方式，就可以用 1 個(gè)或者幾個(gè)線程來(lái)處理大量的連接了，極大的提升了吐吞量Redis 客戶端與 Redis 服務(wù)端建立連接，發(fā)送命令，Redis 服務(wù)器響應(yīng)命令都是需要通過(guò)事件機(jī)制來(lái)做的，如下圖首先 redis 服務(wù)器運(yùn)行，監(jiān)聽(tīng)套接字的 AE_READABLE 事件處于監(jiān)聽(tīng)的狀態(tài)下，此時(shí)連接應(yīng)答處理器工作
客戶端與 Redis 服務(wù)器發(fā)起建立連接，監(jiān)聽(tīng)套接字產(chǎn)生 AE_READABLE 事件，當(dāng) IO 多路復(fù)用程序監(jiān)聽(tīng)到其準(zhǔn)備就緒后，將該事件壓入隊(duì)列中，由文件事件分派器獲取隊(duì)列中的事件交于連接應(yīng)答處理器工作處理，應(yīng)答客戶端建立連接成功，同時(shí)將客戶端 socket 的 AE_READABLE 事件壓入隊(duì)列由文件事件分派器獲取隊(duì)列中的事件交命令請(qǐng)求處理器關(guān)聯(lián)
客戶端發(fā)送 set key value 請(qǐng)求，客戶端 socket 的 AE_READABLE 事件，當(dāng) IO 多路復(fù)用程序監(jiān)聽(tīng)到其準(zhǔn)備就緒后，將該事件壓入隊(duì)列中，由文件事件分派器獲取隊(duì)列中的事件交于命令請(qǐng)求處理器關(guān)聯(lián)處理
命令請(qǐng)求處理器關(guān)聯(lián)處理完成后，需要響應(yīng)客戶端操作完成，此時(shí)將產(chǎn)生 socket 的 AE_WRITEABLE 事件壓入隊(duì)列，由文件事件分派器獲取隊(duì)列中的事件交于命令恢復(fù)處理器處理，返回操作結(jié)果，完成后將解除 AE_WRITEABLE 事件與命令恢復(fù)處理器的關(guān)聯(lián)
大體上可以說(shuō) Redis 的工作模式是，reactor 模式配合一個(gè)隊(duì)列，用一個(gè) serverAccept 線程來(lái)處理建立請(qǐng)求的鏈接，并且通過(guò) IO 多路復(fù)用模型，讓內(nèi)核來(lái)監(jiān)聽(tīng)這些 socket，一旦某些 socket 的讀寫(xiě)事件準(zhǔn)備就緒后就對(duì)應(yīng)的事件壓入隊(duì)列中，然后 worker 工作，由文件事件分派器從中獲取事件交于對(duì)應(yīng)的處理器去執(zhí)行，當(dāng)某個(gè)事件執(zhí)行完成后文件事件分派器才會(huì)從隊(duì)列中獲取下一個(gè)事件進(jìn)行處理。可以類比在 netty 中，我們一般會(huì)設(shè)置 bossGroup 和 workerGroup 默認(rèn)情況下 bossGroup 為 1，workerGroup = 2 * cpu 數(shù)量，這樣可以由多個(gè)線程來(lái)處理讀寫(xiě)就緒的事件，但是其中不能有比較耗時(shí)的操作如果有的話需要將其放入線程池中，不然會(huì)降低其吐吞量。在 Redis 中我們可以看做這二者的值都是 1。為什么說(shuō)存儲(chǔ)的值不宜過(guò)大
比如一個(gè) string key = a，存儲(chǔ)了 500MB，首先讀取事件壓入隊(duì)列中，文件事件分派器從中獲取到后，交于命令請(qǐng)求處理器處理，此處就涉及到從磁盤中加載 500MB。比如是普通的 SSD 硬盤，讀取速度 200MB/S，那么需要 2.5S 的讀取時(shí)間，在內(nèi)存中讀取數(shù)據(jù)比較快比如 DDR4 中 50G/秒，讀取 500MB 需要 100 毫秒左右。線程的庫(kù)一般默認(rèn) 10 毫秒就算慢查詢了，大部分的指令執(zhí)行時(shí)間都是微秒級(jí)別，此時(shí)其它 socket 所有的請(qǐng)求都將處于等待過(guò)程中，就會(huì)導(dǎo)致阻塞了 100 毫秒，同時(shí)又會(huì)占用較大的帶寬導(dǎo)致吞吐量進(jìn)一步下降。到此，關(guān)于“Redis的設(shè)計(jì)與實(shí)現(xiàn)方法是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！
新聞標(biāo)題：Redis的設(shè)計(jì)與實(shí)現(xiàn)方法是什么
當(dāng)前URL：
http://weahome.cn/article/ieipij.html
重慶分公司
重慶分公司
