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ù)。

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)景

緩存

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

使用緩存遇到的問(wèn)題

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

（2）緩存雪崩

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

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

• 事故前：redis 高可用方案，主從+哨兵，集群方案，避免全盤崩潰；
• 事故中：較少數(shù)據(jù)庫(kù)的壓力，本地 Ehcache 緩存+限流及降級(jí)，避免超過(guò)數(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ù)，如果沒(méi)有再去 Redis 請(qǐng)求數(shù)據(jù)，如果沒(méi)有再去數(shù)據(jù)庫(kù)請(qǐng)求數(shù)據(jù)，獲取到數(shù)據(jù)后同步到 Ehcache 和 redis。

這樣做的好處是:

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

• 在請(qǐng)求接口層可以做一些校驗(yàn)，比如用戶簽權(quán)、參數(shù)校驗(yàn)，不合法的請(qǐng)求直接return；
• 還可以針對(duì)有效id做認(rèn)證或直接攔截，不符合的 id 直接過(guò)濾或采用統(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)求非常頻繁，處于集中式訪問(wèn)現(xiàn)象，當(dāng)這個(gè)key失效(過(guò)期)時(shí)，大量的請(qǐng)求就會(huì)擊穿了緩存，直接請(qǐng)求數(shù)據(jù)庫(kù)，就像在屏障中鑿開了一個(gè)洞。

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

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

為什么Redis這么快

• 使用類似于 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)象，也就不存在考慮各種鎖的問(wèn)題；
• 使用非阻塞IO，多路復(fù)用IO模型。

Redis 淘汰策略

• volatile為前綴的策略都是從已過(guò)期的數(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ù)制的建立過(guò)程；

  接下來(lái)，主節(jié)點(diǎn)就會(huì)持續(xù)的把寫命令發(fā)送給從節(jié)點(diǎn)，保證主從數(shù)據(jù)一致性。

Redis哨兵模式

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

• 一旦主節(jié)點(diǎn)宕機(jī)，從節(jié)點(diǎn)晉升為主節(jié)點(diǎn)，同時(shí)需要修改應(yīng)用方的主節(jié)點(diǎn)地址，還需要命令所有從節(jié)點(diǎn)去復(fù)制新的主節(jié)點(diǎn)，整個(gè)過(guò)程需要人工干預(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)問(wèn)題，Sentinel 通過(guò) 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)的信息。

來(lái)源：https://www.jianshu.com/p/0a1c9fc23c01