您好,登錄后才能下訂單哦!
這篇文章主要介紹“Redis面試常問點有哪些”,在日常操作中,相信很多人在Redis面試常問點有哪些問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Redis面試常問點有哪些”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
存儲方式
Memecache把數據全部存在內存之中,斷電后會掛掉,數據不能超過內存大小。memcached本身是為緩存而設計的服務器,因此沒有考慮數據的永久性問題。
Redis有部份存在硬盤上,這樣能保證數據的持久性。停電后可恢復。
數據支持類型
Memcache對數據類型支持相對簡單。>>Redis有5種數據類型。
線程
Memecache高性能的分布式內存緩存服務器,由于 redis 只使用單核,而 memcached 可以使用多核,
value大小
redis最大可以達到1GB,而memcache只有1MB
純內存操作
核心是基于非阻塞的 IO 多路復用機制
單線程反而避免了多線程的頻繁上下文切換問題
官方現實QPS可達10W/s
問題:目前電商首頁以及熱點數據都會去做,一==緩存 ==般緩存都是定時任務去刷新,或者是查不到之后去查數據庫然后更新的,定時任務刷新就有一個問題。如果所有redis緩存在同一時間失效了,此時正好雙十一秒殺活動則會導致前端所有請求直接打到DB上,如過掛的是一個用戶服務的庫,那其他依賴他的庫所有的接口幾乎都會報錯,如果沒做熔斷等策略基本上就是瞬間掛一片的節奏,
解決方法:在批量往Redis存數據的時候,把每個Key的失效時間都加個隨機值就好了,
setRedis(Key,value,time + Math.random() * 10000);
緩存穿透:指緩存和數據庫中的數都沒有據,而用戶不斷發起請求,我們數據庫的 id 都是1開始自增上去的,如發起為id值為 -1 的數據或 id 為特別大不存在的數據。這時的用戶很可能是攻擊者,攻擊會導致數據庫壓力過大,嚴重會擊垮數據庫。
解決方法:在接口層增加校驗,比如用戶鑒權校驗,參數做校驗,不合法的參數直接代碼Return,比如:id 做基礎校驗,id <=0的直接攔截,IP單位請求次數限制等操作。從緩存取不到的數據,在數據庫中也沒有取到,這時也可以將對應Key的Value對寫為null、位置錯誤、稍后重試這樣的值具體取啥問產品,或者看具體的場景,緩存有效時間可以設置短點,如30秒。
緩存擊穿:這個跟緩存雪崩有點像,但是又有一點不一樣,緩存雪崩是因為大面積的緩存失效,打崩了DB,而緩存擊穿不同的是緩存擊穿是指一個Key非常熱點,在不停的扛著大并發,大并發集中對這一個點進行訪問,當這個Key在失效的瞬間,持續的大并發就穿破緩存,直接請求數據庫,簡單理解為子彈穿透一個物體。
解決方法:設置熱點key用不過期。
Bloom Filter:防止緩存穿透的發生,他的原理也很簡單就是利用高效的數據結構和算法快速判斷出你這個Key是否在數據庫中存在,不存在你return就好了,存在你就去查了DB刷新KV再return。
分布式鎖實現原理, 先拿setnx來爭搶鎖,搶到之后,再用expire給鎖加一個過期時間防止鎖忘記了釋放。
如果在setnx之后,執行expire之前進程意外crash或重啟維護, 那么就需要把setnx和expire合成一條指令來用。
使用keys指令可以掃出指定模式的key列表。
如果這個redis正在給線上的業務提供服務,那么使用key指令會導致線程阻塞。(redis是單線程的,執行key指令期間,線上服務會卡頓,直到指令執行完成,服務才會恢復)。
在這種場景下,就可以使用scan指令,該指令可以的提無阻塞取出指定模式的key列表,但是會有一定重復的概率,可以在客戶端做一次去重就好了, 但是整體花費的時間會比直接使用keys指令長。
一般使用list結構作為隊列,rpush生產消息,lpop消費消息。當lpop沒有消息的時候,要適當sleep一會再重試。(如果不用sleep, list還有個指令blpop, 在沒有消息的時候, 他會阻塞住直到有消息到來)。
如果要生產一次消費多次,則需要使用pub/sub主題訂閱者模式,可以實現1:N的消息隊列。(在消費者下線的情況下,生產的消息會丟失。在這種情況下, 就得使用更專業的消息隊列了,例如RabbitMQ)
RDB:你給出兩個詞匯就可以了,fork和cow。fork是指redis通過創建子進程來進行RDB操作,cow指的是=copy on write===,子進程創建后,父子進程共享數據段,父進程繼續提供讀寫服務,寫臟的頁面數據會逐漸和子進程分離開來。
AOF:保存等其實鎖增修的RESP指令,一般為全量數據,恢復起來較慢也。并且 服務器重啟順序先AOF后RDB
可以將多次IO往返的時間縮減為一次, 前提是pipeline執行的指令質檢沒有因果相關性。使用redis-benchmark進行壓測的時候可以發現影響redis的QPS峰值的一個重要因素是piepline批次指令的數目。
redis可以使用主從同步, 從從同步。第一次同步時, 主節點做一次bgsave, 并同時將后續修改操作記錄到內存buffer, 待完成后將rdb文件全量同步到復制節點, 復制節點接受完成后, 將rdb鏡像加載到內存。加載完成后, 再通知主節點將修改期間的操作 記錄同步到復制節點進行重放就完成了同步過程。
redis sentinal著眼于高可用, 在master宕機時會自動將slave提升為master, 繼續提供服務。
redis cluster著眼于擴展性, 在單個redis內存不足時, 使用cluster進行分片存儲
一般避免以上情況發生我們從三個時間段去分析下:
事前:Redis 高可用,主從+哨兵,Redis cluster,避免全盤崩潰。
事中:本地 ehcache 緩存 + Hystrix 限流+降級,避免MySQL 被打死。
事后:Redis 持久化 RDB+AOF,一旦重啟,自動從磁盤上加載數據,快速恢復緩存數據。
到此,關于“Redis面試常問點有哪些”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。