一、Redis簡(jiǎn)介

Redis 是C語(yǔ)言開發(fā)的一個(gè)開源高性能鍵值對(duì)的內(nèi)存數(shù)據(jù)庫(kù)，可以用來(lái)做數(shù)據(jù)庫(kù)、緩存、消息中間件等場(chǎng)景，是一種NoSQL(not-only sql,非關(guān)系型數(shù)據(jù)庫(kù))的數(shù)據(jù)庫(kù)。

在潞城等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供做網(wǎng)站、成都網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),成都全網(wǎng)營(yíng)銷推廣,成都外貿(mào)網(wǎng)站建設(shè)公司,潞城網(wǎng)站建設(shè)費(fèi)用合理。

二、Redis特點(diǎn)

• 優(yōu)秀的性能，數(shù)據(jù)是存儲(chǔ)在內(nèi)存中，讀寫速度非?？?，可支持并發(fā)10W QPS。
• 單線程但進(jìn)程，是線程安全的，采用IO 多路復(fù)用制。
• 可作為分布式鎖。
• 支持五種數(shù)據(jù)類型。
• 支持?jǐn)?shù)據(jù)持久化到磁盤。
• 可以作為消息中間件使用，支持消息發(fā)布及訂閱。

三、數(shù)據(jù)類型

下表是我列舉的五種數(shù)據(jù)類型的特性及其使用場(chǎng)景

四、緩存

數(shù)據(jù)緩存是Redis最重要的一個(gè)場(chǎng)景，為緩存而生，在springboot中，一般有兩種使用方式：

• 直接通過RedisTemplate使用。
• 通過Spring Cache集成Redis(也就是注解的方式)。

五、使用緩存遇到的問題

(1) 數(shù)據(jù)一致性

在分布式環(huán)境下，緩存和數(shù)據(jù)庫(kù)很容易出現(xiàn)數(shù)據(jù)一致性問題，如果項(xiàng)目對(duì)緩存的要求是強(qiáng)一致性，那就不要使用緩存。

我們只能在項(xiàng)目中使用策略降低緩存與數(shù)據(jù)庫(kù)一致性的概率，是無(wú)法保障兩者的強(qiáng)一致性，一般策略包括緩存更新機(jī)制，更新數(shù)據(jù)庫(kù)后及時(shí)更新緩存、緩存失敗時(shí)增加重試機(jī)制。

(2) 緩存雪崩

在了解雪崩潰之前，我們先了解什么是緩存雪崩現(xiàn)象，假設(shè)A系統(tǒng)每秒需要處理5000個(gè)請(qǐng)求，但數(shù)據(jù)庫(kù)每秒只能處理4000個(gè)請(qǐng)求，某一天，緩存機(jī)器出現(xiàn)了宕機(jī)，掛了，這時(shí)候所有的請(qǐng)求一下子全部落在數(shù)據(jù)庫(kù)上，數(shù)據(jù)庫(kù)肯定扛不住，報(bào)警掛掉了，這時(shí)候如果沒有采取緩存設(shè)施，數(shù)據(jù)庫(kù)又急著用，重新重啟數(shù)據(jù)庫(kù)，剛重啟完成(有可能沒啟動(dòng)完)，請(qǐng)求又來(lái)，數(shù)據(jù)庫(kù)立馬掛掉。這就是雪崩事件，是Redis緩存中最致命問題之一(有一個(gè)是穿透)。大家可以看看下圖 :

出現(xiàn)雪崩事件后不要急不要慌，我們可以在事故前中后三個(gè)方面來(lái)思考解決方案

• 事故前：redis高可用方案，主從+哨兵，集群方案，避免全盤崩潰。
• 事故中：較少數(shù)據(jù)庫(kù)的壓力，本地Ehcache緩存+限流及降級(jí)，避免超過數(shù)據(jù)庫(kù)承受壓力。
• 事故后：做redis持久化，一旦Redis重啟，可從磁盤中快速恢復(fù)數(shù)據(jù)。

我們來(lái)看看改造后的數(shù)據(jù)流程，假設(shè)用戶A發(fā)送一個(gè)請(qǐng)求，系統(tǒng)先請(qǐng)求本地Ehcache是否有數(shù)據(jù)，如果沒有再去Redis請(qǐng)求數(shù)據(jù)，如果沒有再去數(shù)據(jù)庫(kù)請(qǐng)求數(shù)據(jù)，獲取到數(shù)據(jù)后同步到Ehcache和redis

限流組件的作用：可以設(shè)置每秒請(qǐng)求數(shù)次，有多少通過請(qǐng)求，剩余的未通過的可以走降級(jí)處理，返回一些默認(rèn)的值，或者友情提示等默認(rèn)操作。具體流程可以看看下圖：

這樣做的好處是:

• 數(shù)據(jù)庫(kù)安全：在限流組件可用的情況下，數(shù)據(jù)庫(kù)不會(huì)掛掉，限流根據(jù)確保了每秒多少請(qǐng)求能通過。
• 部分請(qǐng)求可以被處理：數(shù)據(jù)庫(kù)沒掛，就意味著至少2/5的請(qǐng)求可以被處理掉。
• 高峰時(shí)期部分請(qǐng)求無(wú)法處理到，需要用戶多次點(diǎn)擊，因?yàn)橹挥?/5的請(qǐng)求被處理，剩下的請(qǐng)求，用戶刷不出來(lái)界面，需要多點(diǎn)擊幾次。
• redis設(shè)置的緩存失效時(shí)間不是設(shè)置成同一個(gè)時(shí)間，可根據(jù)功能、業(yè)務(wù)、請(qǐng)求接口靈活設(shè)置緩存時(shí)間：setRedis(key, value, time+Math.random()*10000)。

(3) 緩存穿透

緩存穿透是指緩存和數(shù)據(jù)庫(kù)中都沒有的數(shù)據(jù)，用戶(黑客)不斷發(fā)起請(qǐng)求，導(dǎo)致請(qǐng)求直接查詢數(shù)據(jù)庫(kù)，這種惡意行為攻擊場(chǎng)景的會(huì)直接導(dǎo)致數(shù)據(jù)庫(kù)掛掉，數(shù)據(jù)流程如下圖所示

處理這種情況相對(duì)比較簡(jiǎn)單點(diǎn)，這種情況是繞過redis或本地緩存直接到達(dá)數(shù)據(jù)庫(kù)，可以采取以下方案：

• 在請(qǐng)求接口層可以做一些校驗(yàn)，比如用戶簽權(quán)、參數(shù)校驗(yàn)，不合法的請(qǐng)求直接return。
• 還可以針對(duì)有效id做認(rèn)證或直接攔截，不符合的id直接過濾或采用統(tǒng)一key保存到redis，下次不合法的id請(qǐng)求時(shí)，直接到緩存中獲取數(shù)據(jù)。
• 采用redis的高級(jí)接口Bloom Filter，利用高效的數(shù)據(jù)結(jié)構(gòu)和算法快速判斷出你這個(gè) Key 是否在數(shù)據(jù)庫(kù)中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return。

(4) 緩存擊穿

上面講的穿透是針對(duì)大面積數(shù)據(jù)請(qǐng)求，那么擊穿是針對(duì)一點(diǎn)(一個(gè)key)來(lái)來(lái)導(dǎo)致redis異常，但某個(gè)key是非常熱點(diǎn)，請(qǐng)求非常頻繁，處于集中式訪問現(xiàn)象，當(dāng)這個(gè)key失效(過期)時(shí)，大量的請(qǐng)求就會(huì)擊穿了緩存，直接請(qǐng)求數(shù)據(jù)庫(kù)，就像在屏障中鑿開了一個(gè)洞。

不同場(chǎng)景下緩存擊穿解決方案

數(shù)據(jù)基本不變：熱點(diǎn)數(shù)據(jù)value基本不更新時(shí)，可以設(shè)置成永不過期

數(shù)據(jù)更新不頻繁：緩存刷新流程耗時(shí)較少時(shí)，可采用redis、zookeeper等分布式中間件的分布式互斥鎖或者本地互斥鎖保證少量的請(qǐng)求能請(qǐng)求到數(shù)據(jù)庫(kù)并重新更新緩存，其他的流程等鎖釋放后才可以訪問新緩存

數(shù)據(jù)更新頻繁：采用定時(shí)線程，在緩存過期前主動(dòng)重新構(gòu)建緩存或延長(zhǎng)過期時(shí)間，保證所有的請(qǐng)求能一直訪問緩存

六、為什么Redis會(huì)如此快

Redis官方介紹可以達(dá)到10W+的QPS，這個(gè)數(shù)據(jù)不比MEMCache差，而且Redis 是單進(jìn)程單線程的模型，完全基于內(nèi)存的操作，CPU不是Redis的瓶頸，Redis的瓶頸是內(nèi)存及網(wǎng)絡(luò)帶寬，有以下特點(diǎn)：

• 使用類似于HashMap的原理，HashMap的查詢及操作的時(shí)間復(fù)雜度是O(1)，且絕大多數(shù)請(qǐng)求是純碎的內(nèi)存操作，數(shù)據(jù)存在內(nèi)存中。
• 數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，對(duì)數(shù)據(jù)操作也簡(jiǎn)單，基于KV。
• 不錯(cuò)死鎖現(xiàn)象采用單線程操作，避免了不必要的上下文切換及競(jìng)爭(zhēng)條件，不存在CPU切換現(xiàn)象，也就不存在考慮各種鎖的問題。
• 使用非阻塞IO，多路復(fù)用IO模型。

七、Redis淘汰策略

• volatile為前綴的策略都是從已過期的數(shù)據(jù)集中進(jìn)行淘汰。
• allkeys為前綴的策略都是面向所有key進(jìn)行淘汰。
• LRU(least recently used)最近最少用到的。
• LFU(Least Frequently Used)最不常用的。
• 它們的觸發(fā)條件都是Redis使用的內(nèi)存達(dá)到閾值時(shí)。

八、Redis持久化

Redis 持久化策略有兩種：

• RDB：快照形式是直接把內(nèi)存中的數(shù)據(jù)保存到一個(gè) dump 的文件中，定時(shí)保存，保存策略。
• AOF：把所有的對(duì) Redis 的服務(wù)器進(jìn)行修改的命令都存到一個(gè)文件里，命令的集合。Redis 默認(rèn)是快照 RDB 的持久化方式。

如果非常關(guān)心你的數(shù)據(jù)，但仍然可以承受數(shù)分鐘內(nèi)的數(shù)據(jù)丟失，那么可以額只使用 RDB 持久。

AOF 將 Redis 執(zhí)行的每一條命令追加到磁盤中，處理巨大的寫入會(huì)降低Redis的性能，不知道你是否可以接受。

數(shù)據(jù)庫(kù)備份和災(zāi)難恢復(fù)：定時(shí)生成 RDB 快照非常便于進(jìn)行數(shù)據(jù)庫(kù)備份，并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比 AOF 恢復(fù)的速度快。

當(dāng)然了，Redis 支持同時(shí)開啟 RDB 和 AOF，系統(tǒng)重啟后，Redis 會(huì)優(yōu)先使用 AOF 來(lái)恢復(fù)數(shù)據(jù)，這樣丟失的數(shù)據(jù)會(huì)最少。

九、Redis 主從復(fù)制

• 從節(jié)點(diǎn)執(zhí)行 slaveof[masterIP][masterPort]，保存主節(jié)點(diǎn)信息。
• 從節(jié)點(diǎn)中的定時(shí)任務(wù)發(fā)現(xiàn)主節(jié)點(diǎn)信息，建立和主節(jié)點(diǎn)的 Socket 連接。
• 從節(jié)點(diǎn)發(fā)送 Ping 信號(hào)，主節(jié)點(diǎn)返回 Pong，兩邊能互相通信。
• 連接建立后，主節(jié)點(diǎn)將所有數(shù)據(jù)發(fā)送給從節(jié)點(diǎn)(數(shù)據(jù)同步)。
• 主節(jié)點(diǎn)把當(dāng)前的數(shù)據(jù)同步給從節(jié)點(diǎn)后，便完成了復(fù)制的建立過程。接下來(lái)，主節(jié)點(diǎn)就會(huì)持續(xù)的把寫命令發(fā)送給從節(jié)點(diǎn)，保證主從數(shù)據(jù)一致性。

十、Redis哨兵模式

我們先說(shuō)說(shuō)主從復(fù)制會(huì)存在問題：

• 一旦主節(jié)點(diǎn)宕機(jī)，從節(jié)點(diǎn)晉升為主節(jié)點(diǎn)，同時(shí)需要修改應(yīng)用方的主節(jié)點(diǎn)地址，還需要命令所有從節(jié)點(diǎn)去復(fù)制新的主節(jié)點(diǎn)，整個(gè)過程需要人工干預(yù)。
• 主節(jié)點(diǎn)的寫能力受到單機(jī)的限制。
• 主節(jié)點(diǎn)的存儲(chǔ)能力受到單機(jī)的限制。
• 原生復(fù)制的弊端在早期的版本中也會(huì)比較突出，比如：Redis 復(fù)制中斷后，從節(jié)點(diǎn)會(huì)發(fā)起 psync。
• 此時(shí)如果同步不成功，則會(huì)進(jìn)行全量同步，主庫(kù)執(zhí)行全量備份的同時(shí)，可能會(huì)造成毫秒或秒級(jí)的卡頓。

哨兵的架構(gòu)模式如下：

該系統(tǒng)可以執(zhí)行以下四個(gè)任務(wù)：

• 監(jiān)控：不斷檢查主服務(wù)器和從服務(wù)器是否正常運(yùn)行。
• 通知：當(dāng)被監(jiān)控的某個(gè) Redis 服務(wù)器出現(xiàn)問題，Sentinel 通過 API 腳本向管理員或者其他應(yīng)用程序發(fā)出通知。
• 自動(dòng)故障轉(zhuǎn)移：當(dāng)主節(jié)點(diǎn)不能正常工作時(shí)，Sentinel 會(huì)開始一次自動(dòng)的故障轉(zhuǎn)移操作，它會(huì)將與失效主節(jié)點(diǎn)是主從關(guān)系的其中一個(gè)從節(jié)點(diǎn)升級(jí)為新的主節(jié)點(diǎn)，并且將其他的從節(jié)點(diǎn)指向新的主節(jié)點(diǎn)，這樣人工干預(yù)就可以免了。
• 配置提供者：在 Redis Sentinel 模式下，客戶端應(yīng)用在初始化時(shí)連接的是 Sentinel 節(jié)點(diǎn)集合，從中獲取主節(jié)點(diǎn)的信息。

網(wǎng)頁(yè)名稱：一文讀懂Redis的前世今生
當(dāng)前URL：http://uogjgqi.cn/article/ccdeise.html