Redis簡(jiǎn)介

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

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ù)庫很容易出現(xiàn)數(shù)據(jù)一致性問題，如果項(xiàng)目對(duì)緩存的要求是強(qiáng)一致性，那就不要使用緩存。

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

（2）緩存雪崩

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

這就是雪崩事件，是 Redis 緩存中最致命問題之一（有一個(gè)是穿透）。大家可以看看下圖：

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

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

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

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

這樣做的好處是:

• 數(shù)據(jù)庫安全：在限流組件可用的情況下，數(shù)據(jù)庫不會(huì)掛掉，限流根據(jù)確保了每秒多少請(qǐng)求能通過；
• 部分請(qǐng)求可以被處理：數(shù)據(jù)庫沒掛，就意味著至少2/5的請(qǐng)求可以被處理掉；
  
• 高峰時(shí)期部分請(qǐng)求無法處理到，需要用戶多次點(diǎn)擊，因?yàn)橹挥?2/5 的請(qǐng)求被處理，剩下的請(qǐng)求，用戶刷不出來界面，需要多點(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ù)庫中都沒有的數(shù)據(jù)，用戶（黑客）不斷發(fā)起請(qǐng)求，導(dǎo)致請(qǐng)求直接查詢數(shù)據(jù)庫，這種惡意行為攻擊場(chǎng)景的會(huì)直接導(dǎo)致數(shù)據(jù)庫掛掉，數(shù)據(jù)流程如下圖所示：

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

• 在請(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ù)庫中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return。
  

（4） 緩存擊穿

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

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

• 數(shù)據(jù)基本不變：熱點(diǎn)數(shù)據(jù)value基本不更新時(shí)，可以設(shè)置成永不過期
• 數(shù)據(jù)更新不頻繁：緩存刷新流程耗時(shí)較少時(shí)，可采用redis、zookeeper等分布式中間件的分布式互斥鎖或者本地互斥鎖保證少量的請(qǐng)求能請(qǐng)求到數(shù)據(jù)庫并重新更新緩存，其他的流程等鎖釋放后才可以訪問新緩存
  
• 數(shù)據(jù)更新頻繁：采用定時(shí)線程，在緩存過期前主動(dòng)重新構(gòu)建緩存或延長(zhǎng)過期時(shí)間，保證所有的請(qǐng)求能一直訪問緩存
  

為什么Redis這么快

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

當(dāng)然了，Redis 支持同時(shí)開啟 RDB 和 AOF，系統(tǒng)重啟后，Redis 會(huì)優(yōu)先使用 AOF 來恢復(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ù)制的建立過程；
  
• 接下來，主節(jié)點(diǎn)就會(huì)持續(xù)的把寫命令發(fā)送給從節(jié)點(diǎn)，保證主從數(shù)據(jù)一致性。
  

Redis哨兵模式

我們先說說主從復(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)行全量同步，主庫執(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)的信息。