redis常問的問題有哪些

Redis 和 Memcached 的區(qū)別

1. 存儲方式

Memecache把數(shù)據(jù)全部存在內(nèi)存之中，斷電后會掛掉，數(shù)據(jù)不能超過內(nèi)存大小。memcached本身是為緩存而設(shè)計的服務(wù)器，因此沒有考慮數(shù)據(jù)的永久性問題。
Redis有部份存在硬盤上，這樣能保證數(shù)據(jù)的持久性。停電后可恢復。

2. 數(shù)據(jù)支持類型
   Memcache對數(shù)據(jù)類型支持相對簡單。>>Redis有5種數(shù)據(jù)類型。

3. 線程
   Memecache高性能的分布式內(nèi)存緩存服務(wù)器,由于 redis 只使用單核，而 memcached 可以使用多核，

4. value大小
   redis最大可以達到1GB，而memcache只有1MB

為啥 redis 單線程模型也能效率這么高？

純內(nèi)存操作
核心是基于非阻塞的 IO 多路復用機制
單線程反而避免了多線程的頻繁上下文切換問題
官方現(xiàn)實QPS可達10W/s

 

redis 緩存雪崩

問題：目前電商首頁以及熱點數(shù)據(jù)都會去做，一==緩存 ==般緩存都是定時任務(wù)去刷新，或者是查不到之后去查數(shù)據(jù)庫然后更新的，定時任務(wù)刷新就有一個問題。如果所有redis緩存在同一時間失效了，此時正好雙十一秒殺活動則會導致前端所有請求直接打到DB上，如過掛的是一個用戶服務(wù)的庫，那其他依賴他的庫所有的接口幾乎都會報錯，如果沒做熔斷等策略基本上就是瞬間掛一片的節(jié)奏，
==解決方法==：在批量往Redis存數(shù)據(jù)的時候，把每個Key的失效時間都加個隨機值就好了，
setRedis（Key，value，time + Math.random() * 10000);

 

redis 緩存穿透，緩存擊穿

==緩存穿透==:指緩存和數(shù)據(jù)庫中的數(shù)==都沒有==據(jù)，而用戶不斷發(fā)起請求，我們數(shù)據(jù)庫的 id 都是1開始自增上去的，如發(fā)起為id值為 -1 的數(shù)據(jù)或 id 為特別大不存在的數(shù)據(jù)。這時的用戶很可能是攻擊者，攻擊會導致數(shù)據(jù)庫壓力過大，嚴重會擊垮數(shù)據(jù)庫。
==解決方法==：在接口層增加校驗，比如用戶鑒權(quán)校驗，參數(shù)做校驗，不合法的參數(shù)直接代碼Return，比如：id 做基礎(chǔ)校驗，id <=0的直接攔截，IP單位請求次數(shù)限制等操作。從緩存取不到的數(shù)據(jù)，在數(shù)據(jù)庫中也沒有取到，這時也可以將對應Key的Value對寫為null、位置錯誤、稍后重試這樣的值具體取啥問產(chǎn)品，或者看具體的場景，緩存有效時間可以設(shè)置短點，如30秒。

==緩存擊穿==：這個跟緩存雪崩有點像，但是又有一點不一樣，緩存雪崩是因為大面積的緩存失效，打崩了DB，而緩存擊穿不同的是緩存擊穿是指一個Key非常熱點，在不停的扛著大并發(fā)，大并發(fā)集中對這一個點進行訪問，當這個Key在失效的瞬間，持續(xù)的大并發(fā)就穿破緩存，直接請求數(shù)據(jù)庫，簡單理解為子彈穿透一個物體。
==解決方法==：設(shè)置熱點key用不過期。

redis 布隆過濾器

Bloom Filter：防止==緩存穿透==的發(fā)生，他的原理也很簡單就是利用高效的數(shù)據(jù)結(jié)構(gòu)和算法快速判斷出你這個Key是否在數(shù)據(jù)庫中存在，不存在你return就好了，存在你就去查了DB刷新KV再return。

redis 分布式鎖

分布式鎖實現(xiàn)原理, 先拿setnx來爭搶鎖,搶到之后,再用expire給鎖加一個過期時間防止鎖忘記了釋放。
如果在setnx之后,執(zhí)行expire之前進程意外crash或重啟維護, 那么就需要把setnx和expire合成一條指令來用。

redis keys*  scan

使用keys指令可以掃出指定模式的key列表。
如果這個redis正在給線上的業(yè)務(wù)提供服務(wù),那么使用key指令會導致線程阻塞。(redis是單線程的,執(zhí)行key指令期間,線上服務(wù)會卡頓,直到指令執(zhí)行完成,服務(wù)才會恢復)。
在這種場景下，就可以使用==scan==指令,該指令可以的提==無阻塞==取出指定模式的key列表,但是會有一定重復的概率,可以在客戶端做一次去重就好了, 但是整體花費的時間會比直接使用keys指令長。

redis 隊列

一般使用list結(jié)構(gòu)作為隊列,rpush生產(chǎn)消息,lpop消費消息。當lpop沒有消息的時候,要適當sleep一會再重試。(如果不用sleep, list還有個指令==blpop==, 在沒有消息的時候, 他會阻塞住直到有消息到來)。
如果要生產(chǎn)一次消費多次,則需要使用pub/sub主題訂閱者模式,可以實現(xiàn)1:N的消息隊列。(在消費者下線的情況下,生產(chǎn)的消息會丟失。在這種情況下, 就得使用更專業(yè)的消息隊列了,例如RabbitMQ)

redis RDB AOF 原理

RDB：你給出兩個詞匯就可以了，==fork==和==cow==。fork是指redis通過創(chuàng)建子進程來進行RDB操作，cow指的是=copy on write===，子進程創(chuàng)建后，父子進程共享數(shù)據(jù)段，父進程繼續(xù)提供讀寫服務(wù)，寫臟的頁面數(shù)據(jù)會逐漸和子進程分離開來。
AOF：保存等其實鎖增修的RESP指令，一般為全量數(shù)據(jù)，恢復起來較慢也。并且 服務(wù)器重啟順序 ==先AOF后RDB==

pipeline有什么好處?

可以將多次IO往返的時間縮減為一次, 前提是pipeline執(zhí)行的指令質(zhì)檢沒有因果相關(guān)性。使用redis-benchmark進行壓測的時候可以發(fā)現(xiàn)影響redis的QPS峰值的一個重要因素是piepline批次指令的數(shù)目。

 

redis的同步機制是如何操作的?

redis可以使用主從同步, 從從同步。第一次同步時, 主節(jié)點做一次bgsave, 并同時將后續(xù)修改操作記錄到內(nèi)存buffer, 待完成后將rdb文件全量同步到復制節(jié)點, 復制節(jié)點接受完成后, 將rdb鏡像加載到內(nèi)存。加載完成后, 再通知主節(jié)點將修改期間的操作 記錄同步到復制節(jié)點進行重放就完成了同步過程。

redis集群的原理?

redis sentinal著眼于高可用, 在master宕機時會自動將slave提升為master, 繼續(xù)提供服務(wù)。
redis cluster著眼于擴展性, 在單個redis內(nèi)存不足時, 使用cluster進行分片存儲

redis 部署方案

一般避免以上情況發(fā)生我們從三個時間段去分析下：

事前：Redis 高可用，主從+哨兵，Redis cluster，避免全盤崩潰。
事中：本地 ehcache 緩存 + Hystrix 限流+降級，避免MySQL 被打死。
事后：Redis 持久化 RDB+AOF，一旦重啟，自動從磁盤上加載數(shù)據(jù)，快速恢復緩存數(shù)據(jù)。