柚子快報激活碼778899分享：數(shù)據(jù)庫 緩存 Redis面經(jīng)

http://yzkb.51969.com/

Redis面經(jīng)

Redis緩存穿透、緩存擊穿和緩存雪崩及解決方案概述？緩存穿透詳解及解決方案？緩存擊穿詳解及解決方案？緩存雪崩詳解及解決方案？

Redis持久化機制什么是數(shù)據(jù)持久化？Redis數(shù)據(jù)持久化的方式有哪些？RDB持久化的優(yōu)缺點？AOF持久化的優(yōu)缺點？混合持久化的優(yōu)缺點？

Redis緩存穿透、緩存擊穿和緩存雪崩及解決方案

概述？

三者的根本原因在于，Redis命中率下降，請求直接打在了數(shù)據(jù)庫上。 在正常的情況下，大部分的資源請求都可以被Redis響應(yīng)，沒有被Redis響應(yīng)的小部分請求會轉(zhuǎn)向數(shù)據(jù)庫，這樣的話，數(shù)據(jù)庫DB的壓力不會太大，是可以正常工作的。然而，如果大量高并發(fā)請求同時打在了Redis上，請求并沒有在Redis上找到相應(yīng)的資源，也就是Redis沒有響應(yīng)，命中率降低。這些請求就只能轉(zhuǎn)向數(shù)據(jù)庫，在大量高并發(fā)的請求之下，導(dǎo)致數(shù)據(jù)庫壓力瞬間增大，從而造成數(shù)據(jù)庫服務(wù)器卡死或者宕機。而導(dǎo)致Redis命中率下降的原因就可以分為三種，分別對應(yīng)著緩存穿透、緩存擊穿和緩存雪崩。

緩存穿透詳解及解決方案？

緩存穿透是指請求根本不存在的資源，數(shù)據(jù)庫中沒有，Redis中更不會有。例如，客戶端發(fā)送大量無法響應(yīng)的請求，類似于“http://localhost:8080/user/199?id=-1”，數(shù)據(jù)庫本身就不存在id=-1的用戶數(shù)據(jù)，Redis中就更不可能存在，那么這些請求就得不到響應(yīng)，就會直接打在數(shù)據(jù)庫上。緩存穿透通常是黑客所為，黑客發(fā)送大量的無法響應(yīng)的請求給服務(wù)器，由于請求的資源根本不存在，從而導(dǎo)致數(shù)據(jù)庫壓力過大而卡死或宕機。 解決方案：

對空值進行緩存：類似于上面的例子，由于數(shù)據(jù)庫中沒有id=-1的用戶數(shù)據(jù)，可以在Redis中對它進行緩存，即key=-1，value=null。這樣的話，當請求到達Redis的時候就會直接返回一個null給客戶端，避免了Redis無法響應(yīng)的問題。需要注意的是，對空值進行緩存時，key的過期時間不能設(shè)置太長，以免占用太多Redis資源，而且對空值進行緩存是一種很被動的防御方式，當遇到黑客請求大量不存在的資源就需要寫入大量的null值到Redis中，可能會導(dǎo)致Redis內(nèi)存不足。實時監(jiān)控，拒絕黑客攻擊：當Redis命中率出現(xiàn)大大下降的情況，就要配合運維人員對訪問對象和訪問數(shù)據(jù)進行分析排查，從而進行黑名單的設(shè)置，拒絕黑客攻擊。使用布隆過濾器：使用BitMap作為布隆過濾器，將可以訪問的資源通過簡單的映射關(guān)系放到布隆過濾器中，例如哈希計算。當請求來臨時，首先將請求放入布隆過濾器進行判斷，如果有相應(yīng)資源則放行，如果沒有則直接攔截。需要注意的是，布隆過濾器是有一定誤差的，一般需要配合其他限制來解決緩存穿透問題。接口校驗。類似于用戶權(quán)限的攔截，對于id=-1這種無效請求直接進行攔截，不允許這些請求到達Redis和數(shù)據(jù)庫上。

緩存擊穿詳解及解決方案？

緩存擊穿是指Redis中某個熱點key過期，此時有大量的用戶訪問該key，大量高并發(fā)的對于該key的請求沒有得到Redis的響應(yīng)，就會轉(zhuǎn)向數(shù)據(jù)庫，導(dǎo)致數(shù)據(jù)庫服務(wù)器癱瘓。 解決方案：

提前對熱點數(shù)據(jù)進行設(shè)置：在一些新聞資訊平臺或軟件上，需要對熱點數(shù)據(jù)提前設(shè)置在Redis緩存中。監(jiān)控數(shù)據(jù)，適時調(diào)整：監(jiān)控哪些數(shù)據(jù)是熱門數(shù)據(jù)，實時調(diào)整key的過期時長。使用鎖機制：只有一個請求可以獲得互斥鎖，請求在數(shù)據(jù)庫中查詢數(shù)據(jù)并將結(jié)果返回給Redis，這樣其他請求就可以從Redis中得到響應(yīng)。

緩存雪崩詳解及解決方案？

緩存雪崩像是緩存擊穿的promax版，Redis中的key集體過期，相當于Redis中的大部分數(shù)據(jù)被清空了或者說是失效了，那么此時Redis中由于沒有相應(yīng)數(shù)據(jù)就無法響應(yīng)大量高并發(fā)的請求，命中率急劇下降，請求都打在了數(shù)據(jù)庫上，數(shù)據(jù)庫服務(wù)器直接崩潰。 解決方案：

將失效時間分散開：使用自動生成隨機數(shù)使得key的過期時間是隨機的，防止集體過期。使用多級緩存架構(gòu)：使用Nginx緩存+Redis緩存+其他緩存，不同層使用不同的緩存，提高了系統(tǒng)的可靠性。設(shè)置緩存標記：記錄緩存數(shù)據(jù)是否過期，如果過期就會觸發(fā)另外的后臺線程實時更新過期的key。使用鎖或者隊列的方式：請求不到的資源加上排它鎖，其他請求就只能等待。

Redis持久化機制

什么是數(shù)據(jù)持久化？

數(shù)據(jù)持久化就是將數(shù)據(jù)從內(nèi)存寫入磁盤，目的在于防止數(shù)據(jù)丟失。內(nèi)存中的數(shù)據(jù)在服務(wù)器重啟或者斷電時會丟失，而磁盤中的數(shù)據(jù)不會，為了確保系統(tǒng)的穩(wěn)定性，需要進行數(shù)據(jù)的持久化操作。

Redis數(shù)據(jù)持久化的方式有哪些？

Redis是一種基于內(nèi)存的數(shù)據(jù)庫，同時，也支持將數(shù)據(jù)寫入數(shù)據(jù)庫，這個過程就叫做Redis數(shù)據(jù)持久化。 Redis持久化方法主要有以下三種：

快照方式（Redis database，RDB）：將某一時刻的內(nèi)存數(shù)據(jù)生成Snapshot快照，以二進制的形式寫入磁盤，由于是以二進制的方式寫入磁盤，因此效率很高，但是一旦Redis意外終止，就會導(dǎo)致部分數(shù)據(jù)丟失。命令追加方式（Append only file，AOF）：記錄Redis數(shù)據(jù)的所有寫操作指令，以文本的形式追加到AOF文件中，由于是以文本的形式寫入，因此效率比較低，但是AOF文件記錄了所有寫操作指令，在Redis服務(wù)重啟時，只需要從頭到尾重新執(zhí)行一遍AOF文件中的命令即可回復(fù)數(shù)據(jù)保證數(shù)據(jù)的完整性?；旌铣志没绞剑篟edis4.0之后新增的方式，結(jié)合了RDB和AOF的優(yōu)點，將RDB 文件和 AOF 日志文件存在一起，這里的 AOF 日志不再是全量的日志，而是自持久化開始到持久化結(jié)束的這段時間發(fā)生的增量 AOF 日志，通常這部分 AOF 日志很小。在寫入的時候，先把當前數(shù)據(jù)以 RDB 形式寫入文件的開頭，再將后續(xù)的操作命令以 AOF 的格式存入文件，這樣既能保證 Redis 重啟時的速度，又能降低數(shù)據(jù)丟失的風(fēng)險。因此，混合持久化適用于對數(shù)據(jù)安全性和性能要求較高的場景。

RDB持久化的優(yōu)缺點？

優(yōu)點：

RDB文件數(shù)據(jù)以二進制的形式存在，占用內(nèi)存小，文件更加緊湊，適合于文件備份。RDB適合災(zāi)難恢復(fù)，由于其文件緊湊，可以更高效率地傳輸給遠程服務(wù)器提供Redis服務(wù)。RDB可以提高Redis的運行速度，每次持久化Redis主線程會fork出一個子進程，子進程負責快照持久化，將內(nèi)存數(shù)據(jù)存儲到磁盤，而Redis主進程繼續(xù)負責處理客戶端請求，不會執(zhí)行磁盤I/O等操作。與AOF格式文件相比，RDB文件可以更快地重啟，因為二進制方式寫入磁盤的效率要比文本方式寫入磁盤的效率要高。

缺點：

由于RDB只能保存某一時間段的數(shù)據(jù)，因此一旦中途Redis服務(wù)意外終止，則會丟失一段時間的Redis數(shù)據(jù)。RDB需要經(jīng)常fork()才能使用子進程將內(nèi)存數(shù)據(jù)持久化在磁盤中，一旦數(shù)據(jù)集過大，fork()會很耗時，如果再加上CPU性能不佳，可能會導(dǎo)致Redis停止為客戶端服務(wù)幾毫秒甚至一秒鐘。

AOF持久化的優(yōu)缺點？

優(yōu)點：

AOF持久化保存的數(shù)據(jù)更加完整。因為AOF提供了三種保存策略：“每次操作保存、每秒鐘保存一次和跟隨系統(tǒng)持久化策略保存”，其中，每秒鐘保存一次是AOF的默認保存策略，從數(shù)據(jù)安全性和性能方面來講都是很不錯的選擇，即使發(fā)生意外，最多丟失一秒鐘的數(shù)據(jù)。AOF采用命令追加的寫入方式，不會出現(xiàn)文件損壞問題，即使有意外情況，也可以使用redis-check-aof工具輕松修復(fù)。AOF持久化文件很容易解析，因為它是把所有Redis鍵值操作命令以文本的形式寫入磁盤，即使不小心使用flush all命令刪除了所有的鍵值信息，只要使用AOF文件刪除最后的flush all命令，重啟Redis服務(wù)即可恢復(fù)之前誤刪的數(shù)據(jù)。

缺點：

對于相同的數(shù)據(jù)集，AOP文件要大于RDB文件。在Redis負載比較高的情況下，RDB要比AOF性能更好。RDB使用快照持久化數(shù)據(jù)，AOF使用命令追加到AOF文件，從數(shù)據(jù)完整性和可靠性的角度來看，RDB比AOF更加健壯、易于維護。

混合持久化的優(yōu)缺點？

優(yōu)點： 既能提高Redis服務(wù)啟動的速度，還能保證數(shù)據(jù)的完整性和安全性，降低了丟失大量數(shù)據(jù)的風(fēng)險。 缺點：

AOF文件中添加了RDB格式的內(nèi)容，使得AOF文件可讀性變差。混合持久化不能在Redis4.0之前的版本使用，兼容性差。

柚子快報激活碼778899分享：數(shù)據(jù)庫 緩存 Redis面經(jīng)

http://yzkb.51969.com/

相關(guān)文章