redis常問的問題有哪些

Redis 和 Memcached 的區別

1. 存儲方式

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

2. 數據支持類型
   Memcache對數據類型支持相對簡單。>>Redis有5種數據類型。

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

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

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

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

 

redis 緩存雪崩

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

 

redis 緩存穿透，緩存擊穿

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

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

redis 布隆過濾器

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

redis 分布式鎖

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

redis keys*  scan

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

redis 隊列

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

redis RDB AOF 原理

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

pipeline有什么好處?

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

 

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

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

redis集群的原理?

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

redis 部署方案

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

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