Redis不知道這些還好意思面試？
不知道redis真的不好意思說自己是干互聯(lián)網(wǎng)的。不管用多用少，用深用淺，總之是用點(diǎn)點(diǎn)。下面是redis相關(guān)網(wǎng)站。
redis中文站
redis官網(wǎng)
Redis 在線測試
Redis 命令參考
redis是什么
Redis（Remote Dictionary Server )，即遠(yuǎn)程字典服務(wù)，是一個(gè)開源的使用ANSI C語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API。
redis與memcache的區(qū)別
memcache的v沒有類型的概念，可以儲存圖片、視頻等。Redis不僅僅支持簡單的k/v類型的數(shù)據(jù)，同時(shí)還提供list，set，hashstring 等數(shù)據(jù)結(jié)構(gòu)的存儲。 redis 單線程，memcache多線程。 Redis雖然是基于內(nèi)存的存儲系統(tǒng)，但是它本身是支持內(nèi)存數(shù)據(jù)的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日志。而memcached是不支持?jǐn)?shù)據(jù)持久化操作的。災(zāi)難恢復(fù)--memcache掛掉后，數(shù)據(jù)不可恢復(fù)。redis數(shù)據(jù)丟失后可以通過aof恢復(fù)。 Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份 應(yīng)用場景不一樣：Redis出來作為NoSQL數(shù)據(jù)庫使用外，還能用做消息隊(duì)列、數(shù)據(jù)堆棧和數(shù)據(jù)緩存等；Memcached適合于緩存SQL語句、數(shù)據(jù)集、用戶臨時(shí)性數(shù)據(jù)、延遲查詢數(shù)據(jù)和session等。
redis為什么那么快
快是redis產(chǎn)生的原因。
redis是基于內(nèi)存的，內(nèi)存的讀寫速度非?？臁?/p>
redis是單線程的，省去了很多上下文切換線程的時(shí)間。當(dāng)然這不是主要原因。最主要的避免了各種鎖的問題。
redis使用多路復(fù)用技術(shù)，可以處理并發(fā)的連接。非阻塞IO 內(nèi)部實(shí)現(xiàn)采用epoll，采用了epoll+自己實(shí)現(xiàn)的簡單的事件框架。epoll中的讀、寫、關(guān)閉、連接都轉(zhuǎn)化成了事件，然后利用epoll的多路復(fù)用特性，絕不在io上浪費(fèi)一點(diǎn)時(shí)間。這里“多路”指的是多個(gè)網(wǎng)絡(luò)連接，“復(fù)用”指的是復(fù)用同一個(gè)線程。采用多路 I/O 復(fù)用技術(shù)可以讓單個(gè)線程高效的處理多個(gè)連接請求（盡量減少網(wǎng)絡(luò)IO的時(shí)間消耗）
redis 優(yōu)秀的存儲結(jié)構(gòu)。
不支持事務(wù)回滾。
redis為甚是單線程
因?yàn)镽edis是基于內(nèi)存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機(jī)器內(nèi)存的大小或者網(wǎng)絡(luò)帶寬。既然單線程容易實(shí)現(xiàn)，而且CPU不會成為瓶頸，那就順理成章地采用單線程的方案了。
如何提高效率？單線程、多進(jìn)程的集群不失為一個(gè)時(shí)髦的解決方案。也可以單機(jī)開多個(gè)redis服務(wù)。
redis value支持的數(shù)據(jù)結(jié)構(gòu)
它支持多種類型的數(shù)據(jù)結(jié)構(gòu)，字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 與范圍查詢， bitmaps， hyperloglogs 和 地理空間（geospatial） 索引半徑查詢。
如何實(shí)現(xiàn)事務(wù)
redis的事務(wù)，本質(zhì)是一組命令的集合。所有的命令都會序列化，然后按順序串行地執(zhí)行。事務(wù)開啟后，所有的命令先入隊(duì)，提交事務(wù)的時(shí)候，要么全執(zhí)行，要么全不執(zhí)行。常用命令如下：
multi 開啟事務(wù)
exec 提交事務(wù)
discard 取消事務(wù)
watch key... 監(jiān)視一個(gè)或多個(gè)key，如果事務(wù)提交前這些key被改動，事務(wù)將被打斷，watch相當(dāng)于樂觀鎖。
unwatch 取消對所有key的監(jiān)視
redis不支持回滾，這和我們以往的理解有點(diǎn)出入。
Redis 命令只會因?yàn)殄e誤的語法而失敗（并且這些問題不能在入隊(duì)時(shí)發(fā)現(xiàn)），或是命令用在了錯誤類型的鍵上面：這也就是說，從實(shí)用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應(yīng)該在開發(fā)的過程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。
因?yàn)椴恍枰獙貪L進(jìn)行支持，所以 Redis的內(nèi)部可以保持簡單且快速。
redis 集群架構(gòu)方案
twemproxy，它類似于一個(gè)代理方式，使用方法和普通redis無任何區(qū)別，設(shè)置好它下屬的多個(gè)redis實(shí)例后，使用時(shí)在本需要連接redis的地方改為連接twemproxy，它會以一個(gè)代理的身份接收請求并使用一致性hash算法，將請求轉(zhuǎn)接到具體redis，將結(jié)果再返回twemproxy。使用方式簡便(相對redis只需修改連接端口)，對舊項(xiàng)目擴(kuò)展的首選。
問題？：基于twemproxy自身單端口實(shí)例的壓力，使用一致性hash后，當(dāng)redis節(jié)點(diǎn)數(shù)量改變時(shí)候，數(shù)據(jù)無法自動移動到新的節(jié)點(diǎn)。
codis，目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在節(jié)點(diǎn)數(shù)量改變情況下，舊節(jié)點(diǎn)數(shù)據(jù)可恢復(fù)到新hash節(jié)點(diǎn)。
redis cluster3.0自帶的集群，特點(diǎn)在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自身支持節(jié)點(diǎn)設(shè)置從節(jié)點(diǎn)。具體看官方文檔介紹。
在業(yè)務(wù)代碼層實(shí)現(xiàn)，起幾個(gè)毫無關(guān)聯(lián)的redis實(shí)例，在代碼層，對key 進(jìn)行hash計(jì)算，然后去對應(yīng)的redis實(shí)例操作數(shù)據(jù)。這種方式對hash層代碼要求比較高，考慮部分包括，節(jié)點(diǎn)失效后的替代算法方案，數(shù)據(jù)震蕩后的自動腳本恢復(fù)，實(shí)例的監(jiān)控，等等。
redis中zset（Sorted Sets）的實(shí)現(xiàn)
參考 redis zset底層實(shí)現(xiàn)原理
有序集合類型 (Sorted Set或ZSet) 相比于集合類型多了一個(gè)排序?qū)傩?score（分值），對于有序集合 ZSet 來說，每個(gè)存儲元素相當(dāng)于有兩個(gè)值組成的，一個(gè)是有序結(jié)合的元素值，一個(gè)是排序值。有序集合保留了集合不能有重復(fù)成員的特性(分值可以重復(fù))，但不同的是，有序集合中的元素可以排序。
一、內(nèi)部實(shí)現(xiàn)# 有序集合是由 ziplist (壓縮列表) 或 skiplist (跳躍表) 組成的。
ziplist：ziplist 編碼的 Zset 使用緊挨在一起的壓縮列表節(jié)點(diǎn)來保存，第一個(gè)節(jié)點(diǎn)保存 member，第二個(gè)保存 score。ziplist 內(nèi)的集合元素按 score 從小到大排序，其實(shí)質(zhì)是一個(gè)雙向鏈表。雖然元素是按 score 有序排序的， 但對 ziplist 的節(jié)點(diǎn)指針只能線性地移動，所以在 REDIS_ENCODING_ZIPLIST 編碼的 Zset 中， 查找某個(gè)給定元素的復(fù)雜度為 O(N)O(N)。
跳表：像這種鏈表加多級索引的結(jié)構(gòu)，就是跳躍表！Redis使用跳躍表作為有序集合鍵的底層實(shí)現(xiàn)之一,如果一個(gè)有序集合包含的元素?cái)?shù)量比較多,又或者有序集合中元素的成員是比較長的字符串時(shí), Redis就會使用跳躍表來作為有序集合健的底層實(shí)現(xiàn)。
redis cluster如何搭建，master-slave模式，如何選主
如何搭建redis集群 --- redis-cluster
redis-cluster引入了一個(gè)哈希槽(slot)的概念，讓數(shù)據(jù)與哈希槽關(guān)聯(lián)，哈希槽再與節(jié)點(diǎn)關(guān)聯(lián)。這樣做的好處就是方便集群節(jié)點(diǎn)的增加或刪除。假如沒有哈希槽，數(shù)據(jù)直接和節(jié)點(diǎn)關(guān)聯(lián)，也就是key直接和節(jié)點(diǎn)關(guān)聯(lián)，如果要刪除一個(gè)節(jié)點(diǎn)，那這個(gè)節(jié)點(diǎn)上的所有key都需要一個(gè)個(gè)地移走，比較麻煩；有了哈希槽，就可以將該節(jié)點(diǎn)上的哈希槽全部移走，比較方便。就好比有一些豆子，沒有哈希槽需要一個(gè)個(gè)地?fù)炱饋?，有哈希槽就是有個(gè)碗裝著這些豆子，直接把碗拿起來就好了。redis-cluster中固定有16384個(gè)哈希槽，假如redis-cluster中有6個(gè)redis實(shí)例，3個(gè)master，每個(gè)master帶1個(gè)(沒有固定是1個(gè)，可以是N個(gè))slave，比如3個(gè)master是A、B、C，它們的slave分別為A1、B1、C1，整個(gè)集群對外表現(xiàn)為一個(gè)整體。當(dāng)你執(zhí)行set k1 v1的時(shí)候，到底是set到哪臺master上去了呢？還是3臺master都有？其實(shí)是每個(gè)master都會分配到一部分哈希槽，比如：
A：0 ~ 5500 B：5501 ~ 11000 C：11001 ~ 16384 set的時(shí)候，對key經(jīng)過一番計(jì)算：slot = CRC16(key) % 16384，就可以拿到哈希槽slot，就可以判斷該key要set到哪個(gè)master上。
3、slave的作用是什么？當(dāng)有數(shù)據(jù)落在A上的時(shí)候，給客戶端返回成功，并且異步將數(shù)據(jù)復(fù)制到A1上。如果A掛了，那么A1就會成為master繼續(xù)提供服務(wù)。但如果A和A1都掛了，那么整個(gè)集群都將不能正常提供服務(wù)，所以每個(gè)master可以多整幾個(gè)slave，保證高可用。而且正因?yàn)閺膍aster復(fù)制數(shù)據(jù)到slave是異步的，所以就有可能master給客戶端返回成功了，還沒來得及將數(shù)據(jù)復(fù)制到slave的時(shí)候，master掛了，然后slave變成了master，而這個(gè)master上是沒有剛才寫的數(shù)據(jù)的，這就出現(xiàn)了寫丟失的情況。如果需要保證強(qiáng)一致性，就要用同步寫的方式，但這將會犧牲性能。
redis過期策略
被動訪問時(shí)判定。 主動輪詢判定。犧牲內(nèi)存，保證性能為王。當(dāng)一些客戶端嘗試訪問它時(shí)，key會被發(fā)現(xiàn)并主動的過期。當(dāng)然，這樣是不夠的，因?yàn)橛行┻^期的keys，永遠(yuǎn)不會訪問他們。無論如何，這些keys應(yīng)該過期，所以定時(shí)隨機(jī)測試設(shè)置keys的過期時(shí)間。所有這些過期的keys將會從密鑰空間刪除。
具體就是Redis每秒10次做的事情：測試隨機(jī)的20個(gè)keys進(jìn)行相關(guān)過期檢測。刪除所有已經(jīng)過期的keys。
如果有多于25%的keys過期， 重復(fù)步奏1. 這是一個(gè)平凡的概率算法，基本上的假設(shè)是，我們的樣本是這個(gè)密鑰控件，并且我們不斷重復(fù)過期檢測，直到過期的keys的百分百低于25%,這意味著，在任何給定的時(shí)刻，最多會清除1/4的過期keys。在復(fù)制AOF文件時(shí)如何處理過期
為了獲得正確的行為而不犧牲一致性，當(dāng)一個(gè)key過期，DEL將會隨著AOF文字一起合成到所有附加的slaves。
在master實(shí)例中，這種方法是集中的，并且不存在一致性錯誤的機(jī)會。然而，當(dāng)slaves連接到master時(shí)，不會獨(dú)立過期keys（會等到master執(zhí)行DEL命令），他們?nèi)匀粫跀?shù)據(jù)集里面存在，所以當(dāng)slave當(dāng)選為master時(shí)淘汰keys會獨(dú)立執(zhí)行，然后成為master。
Reids如何實(shí)現(xiàn)分布式鎖
setnx 設(shè)置時(shí)間 Zookeeper
redis的有哪些持久化方式，優(yōu)缺點(diǎn)是什么
RDB快照：能夠在指定的時(shí)間間隔對數(shù)據(jù)進(jìn)行快照存儲。開啟配置：snapshotting。它非常適用于數(shù)據(jù)集的備份,比如你可以在每個(gè)小時(shí)報(bào)保存一下過去12小時(shí)內(nèi)的數(shù)據(jù),同時(shí)每天保存過去10天的數(shù)據(jù),這樣即使出了問題你也可以根據(jù)需求恢復(fù)到不同版本的數(shù)據(jù)集。
AOF日志：持久化方式，它記錄每次對服務(wù)器寫的操作,當(dāng)服務(wù)器重啟的時(shí)候會重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù)。AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾。Redis還能對AOF文件進(jìn)行后臺重寫,使得AOF文件的體積不至于過大。他是全量數(shù)據(jù)。
如果你只希望你的數(shù)據(jù)在服務(wù)器運(yùn)行的時(shí)候存在,你也可以不使用任何持久化方式。
你也可以同時(shí)開啟兩種持久化方式, 在這種情況下。當(dāng)redis重啟的時(shí)候會優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù),因?yàn)樵谕ǔＧ闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整.最重要的事情是了解RDB和AOF持久化方式的不同,讓我們以RDB持久化方式開始。
RDB優(yōu)缺點(diǎn)：
速度快。 RDB是一個(gè)非常緊湊的文件,它保存了某個(gè)時(shí)間點(diǎn)的數(shù)據(jù)集。 RDB在保存RDB文件時(shí)父進(jìn)程唯一需要做的就是fork出一個(gè)子進(jìn)程,接下來的工作全部由子進(jìn)程來做，父進(jìn)程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
缺點(diǎn)：宕機(jī)重啟的時(shí)候可能會丟失數(shù)據(jù)。即便是你設(shè)置每3分鐘更新一次。也會造成這幾分鐘的丟失。
AOF：開啟 append_only_mode
根據(jù)所使用的fsync策略，AOF的速度可能會慢于RDB。可以使用不同的fsync策略：無fsync,每秒fsync（默認(rèn)）,每次寫的時(shí)候fsync。一旦出現(xiàn)故障，最多丟失1秒的數(shù)據(jù)。在一般情況下，每秒fsync的性能依然非常高， 而關(guān)閉fsync可以讓AOF的速度和RDB一樣快。對于相同的數(shù)據(jù)集來說，AOF文件的體積通常要大于RDB文件的體積。如果AOF被破壞，可使用Redis附帶的redis-check-aof程序，對原來的 AOF 文件進(jìn)行修復(fù)。
Redis 中的哨兵機(jī)制
主從復(fù)制：master會復(fù)制到slave，master負(fù)責(zé)寫，slave負(fù)責(zé)讀。master會把數(shù)據(jù)同步到slave，但是slave不會把數(shù)據(jù)同步到master。所以master不能掛。
哨兵模式：核心還是主從復(fù)制。只不過相對于主從模式在主節(jié)點(diǎn)宕機(jī)導(dǎo)致不可寫的情況下，多了一個(gè)競選機(jī)制——從所有的從節(jié)點(diǎn)競選出新的主節(jié)點(diǎn)。競選機(jī)制的實(shí)現(xiàn)，是依賴于在系統(tǒng)中啟動一個(gè)sentinel進(jìn)程。sentinel特點(diǎn)：
監(jiān)控：它會監(jiān)聽主服務(wù)器和從服務(wù)器之間是否在正常工作。
通知：它能夠通過API告訴系統(tǒng)管理員或者程序，集群中某個(gè)實(shí)例出了問題。
故障轉(zhuǎn)移：它在主節(jié)點(diǎn)出了問題的情況下，會在所有的從節(jié)點(diǎn)中競選出一個(gè)節(jié)點(diǎn)，并將其作為新的主節(jié)點(diǎn)。
提供主服務(wù)器地址：它還能夠向使用者提供當(dāng)前主節(jié)點(diǎn)的地址。這在故障轉(zhuǎn)移后，使用者不用做任何修改就可以知道當(dāng)前主節(jié)點(diǎn)地址。
當(dāng)競選出新的主節(jié)點(diǎn)后，被選為新的主節(jié)點(diǎn)的從節(jié)點(diǎn)的配置信息會被sentinel改寫為舊的主節(jié)點(diǎn)的配置信息。完成改寫后，再將新主節(jié)點(diǎn)的配置廣播給所有的從節(jié)點(diǎn)。
Redis集群（cluster） Redis 集群是一個(gè)提供在多個(gè)Redis間節(jié)點(diǎn)間共享數(shù)據(jù)的程序集。
Redis Cluster集群的搭建與實(shí)踐
redis最開始使用主從模式做集群，若master宕機(jī)需要手動配置slave轉(zhuǎn)為master；后來為了高可用提出來哨兵模式，該模式下有一個(gè)哨兵監(jiān)視master和slave，若master宕機(jī)可自動將slave轉(zhuǎn)為master，但它也有一個(gè)問題，就是不能動態(tài)擴(kuò)充；所以在3.x提出cluster集群模式。
Redis-Cluster采用無中心結(jié)構(gòu)，每個(gè)節(jié)點(diǎn)保存數(shù)據(jù)和整個(gè)集群狀態(tài),每個(gè)節(jié)點(diǎn)都和其他所有節(jié)點(diǎn)連接。
Redis 集群的數(shù)據(jù)分片 Redis 集群沒有使用一致性hash, 而是引入了 哈希槽的概念.
Redis 集群有16384個(gè)哈希槽,每個(gè)key通過CRC16校驗(yàn)后對16384取模來決定放置哪個(gè)槽.集群的每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分hash槽,舉個(gè)例子,比如當(dāng)前集群有3個(gè)節(jié)點(diǎn),那么:
節(jié)點(diǎn) A 包含 0 到 5500號哈希槽. 節(jié)點(diǎn) B 包含5501 到 11000 號哈希槽. 節(jié)點(diǎn) C 包含11001 到 16384號哈希槽.
獲取數(shù)據(jù): 如果存入一個(gè)值，按照redis cluster哈希槽的算法：CRC16('key')384 = 6782。那么就會把這個(gè)key 的存儲分配到 B 上了。同樣，當(dāng)我連接(A,B,C)任何一個(gè)節(jié)點(diǎn)想獲取'key'這個(gè)key時(shí)，也會這樣的算法，然后內(nèi)部跳轉(zhuǎn)到B節(jié)點(diǎn)上獲取數(shù)據(jù)
新增一個(gè)主節(jié)點(diǎn): 新增一個(gè)節(jié)點(diǎn)D，redis cluster的這種做法是從各個(gè)節(jié)點(diǎn)的前面各拿取一部分slot到D上，我會在接下來的實(shí)踐中實(shí)驗(yàn)。大致就會變成這樣：
節(jié)點(diǎn)A覆蓋1365-5460
節(jié)點(diǎn)B覆蓋6827-10922
節(jié)點(diǎn)C覆蓋12288-16383
節(jié)點(diǎn)D覆蓋0-1364,5461-6826,10923-12287
同樣刪除一個(gè)節(jié)點(diǎn)也是類似，移動完成后就可以刪除這個(gè)節(jié)點(diǎn)了
Redis 集群的主從復(fù)制模型 為了使在部分節(jié)點(diǎn)失敗或者大部分節(jié)點(diǎn)無法通信的情況下集群仍然可用，所以集群使用了主從復(fù)制模型,每個(gè)節(jié)點(diǎn)都會有N-1個(gè)復(fù)制品. 在我們例子中具有A，B，C三個(gè)節(jié)點(diǎn)的集群,在沒有復(fù)制模型的情況下,如果節(jié)點(diǎn)B失敗了，那么整個(gè)集群就會以為缺少5501-11000這個(gè)范圍的槽而不可用.
然而如果在集群創(chuàng)建的時(shí)候（或者過一段時(shí)間）我們?yōu)槊總€(gè)節(jié)點(diǎn)添加一個(gè)從節(jié)點(diǎn)A1，B1，C1,那么整個(gè)集群便有三個(gè)master節(jié)點(diǎn)和三個(gè)slave節(jié)點(diǎn)組成，這樣在節(jié)點(diǎn)B失敗后，集群便會選舉B1為新的主節(jié)點(diǎn)繼續(xù)服務(wù)，整個(gè)集群便不會因?yàn)椴壅也坏蕉豢捎昧?/p>
不過當(dāng)B和B1 都失敗后，集群是不可用的.
redis大key問題怎么解決，比如一個(gè)key對應(yīng)的value有幾十萬的byte
Redis大key的一些場景及問題
大key場景
Redis使用者應(yīng)該都遇到過大key相關(guān)的場景，比如：
熱門話題下評論、答案排序場景。
大V的粉絲列表。
使用不恰當(dāng)，或者對業(yè)務(wù)預(yù)估不準(zhǔn)確、不及時(shí)進(jìn)行處理垃圾數(shù)據(jù)等。
解決方案：
分拆成幾個(gè)key-value。multiGet取值。 可以對存儲元素按一定規(guī)則進(jìn)行分類，分散存儲到多個(gè)redis實(shí)例中。 拆分之后可以考慮采用pipeline去取，由于redis是單線程的，一次只能執(zhí)行一個(gè)命令，這里采用Pipeline模式，一次發(fā)送多個(gè)命令，無需等待服務(wù)端返回。這樣就大大的減少了網(wǎng)絡(luò)往返時(shí)間，提高了系統(tǒng)性能。
redis 擊穿、穿透、雪崩
擊穿 ：緩存擊穿指的是使用不存在的key進(jìn)行大量的高并發(fā)查詢，這導(dǎo)致緩存無法命中，每次請求都要擊穿到后端數(shù)據(jù)庫系統(tǒng)進(jìn)行查詢，使數(shù)據(jù)庫壓力過大，甚至使數(shù)據(jù)庫服務(wù)被壓死。比如redis冷數(shù)據(jù)的key剛清空，就來了一大批數(shù)據(jù)直達(dá)數(shù)據(jù)庫，某個(gè)key被擊穿。
解決方案：第一個(gè)請求發(fā)現(xiàn)key不存在的時(shí)候，先setnx，只有獲取鎖成功的那個(gè)線程可以查數(shù)據(jù)庫并回寫緩存。其他線程隨機(jī)等到一段時(shí)間。但是setnx可能會掛，發(fā)生死鎖。所以要加過期時(shí)間。
穿透
緩存穿透的概念是，用戶想要查詢一個(gè)數(shù)據(jù)，redis內(nèi)存數(shù)據(jù)庫沒有，持久層數(shù)據(jù)也沒有，于是本次查詢失敗。當(dāng)用戶很多的時(shí)候，緩存都沒有命中，于是都去請求了持久層數(shù)據(jù)庫。這會給持久層數(shù)據(jù)庫造成很大的壓力，這時(shí)候就相當(dāng)于出現(xiàn)了緩存穿透。
解決方案：
布隆過濾器
雪崩 緩存雪崩指緩存服務(wù)器重啟或者大量緩存集中在某一個(gè)時(shí)間段內(nèi)失效，給后端數(shù)據(jù)庫造成瞬時(shí)的負(fù)載升高的壓力，甚至壓垮數(shù)據(jù)庫的情況。
通常的解決辦法是過期時(shí)間散開：對不同的數(shù)據(jù)使用不同的失效時(shí)間，甚至對相同的數(shù)據(jù)、不同的請求使用不同的失效時(shí)間。
我們總結(jié)了在使用redis的過程中遇到的棘手問題以及解決方案，希望對大家有所幫助。記得點(diǎn)在看哦。