這篇文章主要介紹“Redis的技術(shù)要點(diǎn)有哪些”的相關(guān)知識(shí)，小編通過實(shí)際案例向大家展示操作過程，操作方法簡(jiǎn)單快捷，實(shí)用性強(qiáng)，希望這篇“Redis的技術(shù)要點(diǎn)有哪些”文章能幫助大家解決問題。

為渭源等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及渭源網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站建設(shè)、成都網(wǎng)站制作、渭源網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

一、為什么使用Redis

筆者認(rèn)為，在項(xiàng)目中使用Redis，主要是從兩個(gè)角度去考慮：性能和并發(fā)。當(dāng)然，Redis還具備可做分布式鎖等功能的其它功能，但如果只是為了分布式鎖這些其它功能，完全還有其它中間件（如Zookpeer等）可以代替，并不是非要使用Redis。

因此，這個(gè)問題主要從性能和并發(fā)兩個(gè)角度去答：

1、性能

如下圖所示，我們?cè)谂龅叫枰獔?zhí)行耗時(shí)特別久、且結(jié)果不頻繁變動(dòng)的SQL時(shí)，就特別適合將運(yùn)行結(jié)果放入緩存。這樣，后面的請(qǐng)求就去緩存中讀取，使得請(qǐng)求能夠迅速響應(yīng)。

題外話：忽然想聊一下這個(gè)迅速響應(yīng)的標(biāo)準(zhǔn)——其實(shí)根據(jù)交互效果的不同，這個(gè)響應(yīng)時(shí)間沒有固定標(biāo)準(zhǔn)。不過曾經(jīng)有人這么告訴我：“在理想狀態(tài)下，我們的頁面跳轉(zhuǎn)需要在瞬間解決，對(duì)于頁內(nèi)操作則需要在剎那間解決。另外，超過一彈指的耗時(shí)操作要有進(jìn)度提示，并且可以隨時(shí)中止或取消，這樣才能給用戶最好的體驗(yàn)?！?/p>

那么瞬間、剎那、一彈指具體是多少時(shí)間呢？

根據(jù)《摩訶僧祗律》記載：一剎那者為一念，二十念為一瞬，二十瞬為一彈指，二十彈指為一羅預(yù)，二十羅預(yù)為一須臾，一日一夜有三十須臾。

那么，經(jīng)過周密的計(jì)算，一瞬間為0.36秒,一剎那有0.018秒，一彈指長(zhǎng)達(dá)7.2秒。

2、并發(fā)

如下圖所示，在大并發(fā)的情況下，所有的請(qǐng)求直接訪問數(shù)據(jù)庫，數(shù)據(jù)庫會(huì)出現(xiàn)連接異常。這個(gè)時(shí)候，就需要使用Redis做一個(gè)緩沖操作，讓請(qǐng)求先訪問到Redis，而不是直接訪問數(shù)據(jù)庫。

二、使用Redis有什么缺點(diǎn)

大家用Redis這么久，這個(gè)問題是必須要了解的，基本上使用Redis都會(huì)碰到一些問題，常見的主要是四方面的問題：

1、緩存和數(shù)據(jù)庫雙寫一致性問題

2、緩存雪崩問題

3、緩存擊穿問題

4、緩存的并發(fā)競(jìng)爭(zhēng)問題

這四個(gè)問題，筆者個(gè)人覺得在項(xiàng)目中比較常遇見，具體解決方案，后文會(huì)給出。

三、單線程的Redis為什么這么快

這個(gè)問題其實(shí)是對(duì)Redis內(nèi)部機(jī)制的一個(gè)考察。其實(shí)根據(jù)筆者的面試經(jīng)驗(yàn)，很多人其實(shí)都不知道Redis是單線程工作模型。所以，這個(gè)問題還是應(yīng)該要復(fù)習(xí)一下的。主要是以下三點(diǎn)：

1、純內(nèi)存操作

2、單線程操作，避免了頻繁的上下文切換

3、采用了非阻塞I/O多路復(fù)用機(jī)制

我們現(xiàn)在仔細(xì)地說一說I/O多路復(fù)用機(jī)制，因?yàn)檫@個(gè)說法實(shí)在是太通俗了，通俗到一般人都不懂是什么意思。打一個(gè)比方：小曲在S城開了一家快遞店，負(fù)責(zé)同城快送服務(wù)。小曲因?yàn)橘Y金限制，雇傭了一批快遞員，然后小曲發(fā)現(xiàn)資金不夠了，只夠買一輛車送快遞。

經(jīng)營方式一：

客戶每送來一份快遞，小曲就讓一個(gè)快遞員盯著，然后快遞員開車去送快遞。慢慢的小曲就發(fā)現(xiàn)了這種經(jīng)營方式存在很多問題，幾十個(gè)快遞員基本上時(shí)間都花在了搶車上了，大部分快遞員都處在閑置狀態(tài)，誰搶到了車，誰就能去送快遞。

隨著快遞的增多，快遞員也越來越多，小曲發(fā)現(xiàn)快遞店里越來越擠，沒辦法雇傭新的快遞員了，快遞員之間的協(xié)調(diào)很花時(shí)間，大部分時(shí)間花在搶車上。綜合上述缺點(diǎn)，小曲痛定思痛，提出了下面的經(jīng)營方式↓

經(jīng)營方式二：

小曲只雇傭一個(gè)快遞員，客戶送來的快遞，小曲按送達(dá)地點(diǎn)標(biāo)注好，然后依次放在一個(gè)地方。最后，那個(gè)快遞員依次去取快遞，一次拿一個(gè)，開著車去送快遞，送好了就回來拿下一個(gè)快遞。

上述兩種經(jīng)營方式對(duì)比，是不是明顯覺得第二種，效率更高、更好呢？在上述比喻中：

1、每個(gè)快遞員→每個(gè)線程

2、每個(gè)快遞→每個(gè)Socket(I/O流)

3、快遞的送達(dá)地點(diǎn)→Socket的不同狀態(tài)

4、客戶送快遞請(qǐng)求→來自客戶端的請(qǐng)求

5、小曲的經(jīng)營方式→服務(wù)端運(yùn)行的代碼

6、一輛車→CPU的核數(shù)

于是我們有如下結(jié)論：

1、經(jīng)營方式一就是傳統(tǒng)的并發(fā)模型，每個(gè)I/O流(快遞)都有一個(gè)新的線程(快遞員)管理。

2、經(jīng)營方式二就是I/O多路復(fù)用。只有單個(gè)線程(一個(gè)快遞員)，通過跟蹤每個(gè)I/O流的狀態(tài)(每個(gè)快遞的送達(dá)地點(diǎn))，來管理多個(gè)I/O流。

下面類比到真實(shí)的Redis線程模型，如圖所示：

參照上圖，簡(jiǎn)單來說就是，我們的Redis-client在操作的時(shí)候，會(huì)產(chǎn)生具有不同事件類型的Socket。在服務(wù)端，有一段I/O多路復(fù)用程序，將其置入隊(duì)列之中。然后文件事件分派器依次去隊(duì)列中取，轉(zhuǎn)發(fā)到不同的事件處理器中。

需要說明的是，這個(gè)I/O多路復(fù)用機(jī)制，Redis還提供了Select、Epoll、Evport、Kqueue等多路復(fù)用函數(shù)庫，大家可以自行去了解。

四、Redis的數(shù)據(jù)類型及各自使用場(chǎng)景

看到這個(gè)問題，是不是覺得它很基礎(chǔ)？其實(shí)筆者也這么覺得。然而根據(jù)面試經(jīng)驗(yàn)發(fā)現(xiàn)，至少80%的人答不上這個(gè)問題。建議在項(xiàng)目中用到后，再類比記憶，體會(huì)更深，不要硬記。基本上，一個(gè)合格的程序員五種類型都會(huì)用到：

1、String

這個(gè)其實(shí)沒什么好說的，最常規(guī)的Set/Get操作，Value可以是String也可以是數(shù)字，一般做一些復(fù)雜的計(jì)數(shù)功能的緩存。

2、Hash

這里Value存放的是結(jié)構(gòu)化的對(duì)象，比較方便的就是操作其中的某個(gè)字段。筆者在做單點(diǎn)登錄的時(shí)候，就是用這種數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)用戶信息，以CookieId作為Key，設(shè)置30分鐘為緩存過期時(shí)間，能很好地模擬出類似Session的效果。

3、List

使用List的數(shù)據(jù)結(jié)構(gòu)，可以做簡(jiǎn)單的消息隊(duì)列的功能。另外還有一個(gè)就是，可以利用Lrange命令，做基于Redis的分頁功能，性能極佳，用戶體驗(yàn)好。

4、Set

因?yàn)镾et堆放的是一堆不重復(fù)值的集合，所以可以做全局去重的功能。

為什么不用JVM自帶的Set進(jìn)行去重？因?yàn)槲覀兊南到y(tǒng)一般都是集群部署，使用JVM自帶的Set比較麻煩，難道為了做一個(gè)全局去重，再起一個(gè)公共服務(wù)？太麻煩了。

另外，就是利用交集、并集、差集等操作，可以計(jì)算共同喜好、全部的喜好、自己獨(dú)有的喜好等功能。

5、Sorted Set

Sorted Set多了一個(gè)權(quán)重參數(shù)Score，集合中的元素能夠按Score進(jìn)行排列?？梢宰雠判邪駪?yīng)用，取TOP N操作。另外，Sorted Set還可以用來做延時(shí)任務(wù)。最后一個(gè)應(yīng)用就是可以做范圍查找。

五、Redis的過期策略及內(nèi)存淘汰機(jī)制

這個(gè)問題其實(shí)相當(dāng)重要，從這個(gè)問題就可以看出來到底R(shí)edis有沒有用到位。比如，你Redis只能存5G數(shù)據(jù)，可是你寫了10G，那會(huì)刪5G的數(shù)據(jù)。怎么刪的？這個(gè)問題思考過么？還有，你的數(shù)據(jù)已經(jīng)設(shè)置了過期時(shí)間，但是時(shí)間到了，內(nèi)存占用率還是比較高，有思考過原因么?

Redis采用的是定期刪除+惰性刪除策略。

為什么不用定時(shí)刪除策略？

定時(shí)刪除，用一個(gè)定時(shí)器來負(fù)責(zé)監(jiān)視Key，過期則自動(dòng)刪除。雖然內(nèi)存及時(shí)釋放，但是十分消耗CPU資源。在大并發(fā)請(qǐng)求下，CPU要將時(shí)間應(yīng)用在處理請(qǐng)求，而不是刪除Key，因此沒有采用這一策略。

定期刪除+惰性刪除是如何工作的呢？

定期刪除，Redis默認(rèn)每個(gè)100ms檢查是否有過期的Key，有過期Key則刪除。需要說明的是，Redis不是每個(gè)100ms將所有的Key檢查一次，而是隨機(jī)抽取進(jìn)行檢查（如果每隔100ms，全部Key進(jìn)行檢查，Redis豈不是卡死）。因此，如果只采用定期刪除策略，會(huì)導(dǎo)致很多Key到時(shí)間沒有刪除。

于是，惰性刪除派上用場(chǎng)。也就是說在你獲取某個(gè)Key的時(shí)候，Redis會(huì)檢查一下，這個(gè)Key如果設(shè)置了過期時(shí)間，那么是否過期了？如果過期了此時(shí)就會(huì)刪除。

采用定期刪除+惰性刪除就沒其他問題了么？

不是的，如果定期刪除沒刪除Key。然后你也沒及時(shí)去請(qǐng)求Key，也就是說惰性刪除也沒生效。這樣，Redis的內(nèi)存會(huì)越來越高，那么就應(yīng)該采用內(nèi)存淘汰機(jī)制。

在Redis.conf中有一行配置：

# maxmemory-policy volatile-lru

該配置就是配內(nèi)存淘汰策略的：

Noeviction：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，新寫入操作會(huì)報(bào)錯(cuò)。應(yīng)該沒人使用吧；

Allkeys-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在鍵空間中，移除最近最少使用的Key。推薦使用，目前項(xiàng)目在用這種；

Allkeys-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在鍵空間中，隨機(jī)移除某個(gè)key，應(yīng)該也沒人使用吧；

Volatile-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過期時(shí)間的鍵空間中，移除最近最少使用的Key。這種情況一般是把Redis既當(dāng)緩存又做持久化存儲(chǔ)的時(shí)候才用。不推薦；

Volatile-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過期時(shí)間的鍵空間中，隨機(jī)移除某個(gè)Key。依然不推薦；

Volatile-ttl：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過期時(shí)間的鍵空間中，有更早過期時(shí)間的Key優(yōu)先移除。不推薦。

PS：如果沒有設(shè)置Expire的Key，不滿足先決條件（Prerequisites）；那么Volatile-lru、Volatile-random和Volatile-ttl策略的行為，和Noeviction（不刪除）基本上一致。

六、Redis和數(shù)據(jù)庫雙寫一致性問題

一致性問題是分布式常見問題，還可以再分為最終一致性和強(qiáng)一致性。數(shù)據(jù)庫和緩存雙寫，就必然會(huì)存在不一致的問題，想要回答這個(gè)問題，就要先明白一個(gè)前提：如果對(duì)數(shù)據(jù)有強(qiáng)一致性要求，就不能放緩存。我們所做的一切，只能保證最終一致性。

另外，我們所做的方案其實(shí)從根本上來說，只能說降低不一致發(fā)生的概率，無法完全避免。因此，有強(qiáng)一致性要求的數(shù)據(jù)不能放緩存。

《分布式數(shù)據(jù)庫與緩存雙寫一致性方案解疑》

給出了詳細(xì)的分析，在這里簡(jiǎn)單地說一說：首先，采取正確更新策略，先更新數(shù)據(jù)庫，再刪緩存；其次，因?yàn)榭赡艽嬖趧h除緩存失敗的問題，提供一個(gè)補(bǔ)償措施即可，例如利用消息隊(duì)列。

七、應(yīng)對(duì)緩存穿透和緩存雪崩問題

關(guān)于“如何應(yīng)對(duì)緩存穿透和緩存雪崩”這兩個(gè)問題，說句實(shí)在話，一般中小型傳統(tǒng)軟件企業(yè)很難碰到。如果有大并發(fā)的項(xiàng)目，流量有幾百萬左右，這兩個(gè)問題一定要深刻考慮：

1、應(yīng)對(duì)緩存穿透

緩存穿透，即黑客故意去請(qǐng)求緩存中不存在的數(shù)據(jù)，導(dǎo)致所有的請(qǐng)求都懟到數(shù)據(jù)庫上，從而數(shù)據(jù)庫連接異常。

解決方案：

利用互斥鎖，緩存失效的時(shí)候，先去獲得鎖，得到鎖了，再去請(qǐng)求數(shù)據(jù)庫，沒得到鎖，則休眠一段時(shí)間重試；

1、采用異步更新策略，無論Key是否取到值，都直接返回。Value值中維護(hù)一個(gè)緩存失效時(shí)間，緩存如果過期，異步起一個(gè)線程去讀數(shù)據(jù)庫，更新緩存，需要做緩存預(yù)熱（項(xiàng)目啟動(dòng)前，先加載緩存）操作；

2、提供一個(gè)能迅速判斷請(qǐng)求是否有效的攔截機(jī)制，比如利用布隆過濾器，內(nèi)部維護(hù)一系列合法有效的Key，迅速判斷出，請(qǐng)求所攜帶的Key是否合法有效，如果不合法，則直接返回。

2、應(yīng)對(duì)緩存雪崩

緩存雪崩，即緩存同一時(shí)間大面積的失效，這個(gè)時(shí)候又來了一波請(qǐng)求，結(jié)果請(qǐng)求都懟到數(shù)據(jù)庫上，從而導(dǎo)致數(shù)據(jù)庫連接異常。

解決方案：

1、給緩存的失效時(shí)間加上一個(gè)隨機(jī)值，避免集體失效；

2、使用互斥鎖，但是該方案吞吐量明顯下降了；

3、雙緩存。我們有兩個(gè)緩存，緩存A和緩存B。緩存A的失效時(shí)間為20分鐘，緩存B不設(shè)失效時(shí)間，自己做緩存預(yù)熱操作。

然后細(xì)分以下幾個(gè)小點(diǎn)：

a. 從緩存A讀數(shù)據(jù)庫，有則直接返回；

b. A 沒有數(shù)據(jù)，直接從B讀數(shù)據(jù)，直接返回，并且異步啟動(dòng)一個(gè)更新線程；

c. 更新線程同時(shí)更新緩存A和緩存B。

八、如何解決Redis并發(fā)競(jìng)爭(zhēng)Key問題

這個(gè)問題大致就是同時(shí)有多個(gè)子系統(tǒng)去Set一個(gè)Key。這個(gè)時(shí)候要注意什么呢？本人提前百度了一下，發(fā)現(xiàn)大家思考的答案基本都是推薦用Redis事務(wù)機(jī)制。但本人不推薦使用Redis的事務(wù)機(jī)制。因?yàn)槲覀兊纳a(chǎn)環(huán)境，基本都是Redis集群環(huán)境，做了數(shù)據(jù)分片操作。你一個(gè)事務(wù)中有涉及到多個(gè)Key操作的時(shí)候，這多個(gè)Key不一定都存儲(chǔ)在同一個(gè)Redis-Server上。因此，Redis的事務(wù)機(jī)制，十分雞肋。

解決方法如下：

如果對(duì)這個(gè)Key操作不要求順序

這種情況下，準(zhǔn)備一個(gè)分布式鎖，大家去搶鎖，搶到鎖就做Set操作即可，比較簡(jiǎn)單。

如果對(duì)這個(gè)Key操作要求順序

假設(shè)有一個(gè)Key1，系統(tǒng)A需要將Key1設(shè)置為ValueA，系統(tǒng)B需要將Key1設(shè)置為ValueB，系統(tǒng)C需要將Key1設(shè)置為ValueC。期望按照Key1的Value值按照 ValueA→ValueB→ValueC的順序變化。這種時(shí)候我們?cè)跀?shù)據(jù)寫入數(shù)據(jù)庫的時(shí)候，需要保存一個(gè)時(shí)間戳。假設(shè)時(shí)間戳如下：

1、系統(tǒng)A Key 1 {ValueA  3:00}

2、系統(tǒng)B Key 1 {ValueB  3:05}

3、系統(tǒng)C Key 1 {ValueC  3:10}

那么，假設(shè)這會(huì)系統(tǒng)B先搶到鎖，將Key1設(shè)置為{ValueB 3:05}。接下來系統(tǒng)A搶到鎖，發(fā)現(xiàn)自己的ValueA的時(shí)間戳早于緩存中的時(shí)間戳，那就不做Set操作了。以此類推。

關(guān)于“Redis的技術(shù)要點(diǎn)有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。

分享名稱：Redis的技術(shù)要點(diǎn)有哪些-創(chuàng)新互聯(lián)
鏈接URL：http://jinyejixie.com/article6/pijog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)公司、網(wǎng)站收錄、手機(jī)網(wǎng)站建設(shè)、虛擬主機(jī)、標(biāo)簽優(yōu)化、用戶體驗(yàn)

廣告

聲明：本網(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í)需注明來源： 創(chuàng)新互聯(lián)