《【面試突擊】— Redis篇》--Redis Cluster及緩存使用和架構設計的常見問題

能堅持別人不能堅持的,才能擁有別人未曾擁有的。
關注編程大道公眾號,讓我們一同堅持心中所想,一起成長!!

《【面試突擊】— Redis篇》--Redis Cluster及緩存使用和架構設計的常見問題

在這個系列里,我會整理一些面試題與大家分享,幫助年后和我一樣想要在金三銀四準備跳槽的同學。
我們一起鞏固、突擊面試官常問的一些面試題,加油!!

《【面試突擊】— Redis篇》--Redis數據類型?適用于哪些場景?

《【面試突擊】— Redis篇》--Redis的線程模型了解嗎?為啥單線程效率還這么高?

《【面試突擊】— Redis篇》-- Redis的主從復制?哨兵機制?

《【面試突擊】— Redis篇》-- Redis哨兵原理及持久化機制

說說Redis cluster

在redis cluster集群架構中,可以由N個redis master node組成,每個master node都可以掛載多個slave node。
可以自動將數據進行分片,每個master上放一部分數據;
還提供內置的高可用支持,部分master不可用時,還是可以繼續工作的,因為每個master都有salve節點,那么如果mater掛掉,redis cluster這套機制,就會自動將某個slave切換成master;
支持讀寫分離:對于每個master來說,都負責寫請求,寫就寫到master,然后讀就從mater對應的slave去讀;

總結:redis cluster(多master + 讀寫分離 + 高可用)

我們只要基于redis cluster去搭建redis集群即可,不需要再手工去搭建replication復制+主從架構+讀寫分離+哨兵集群+高可用,不需要這樣去搭了。

redis cluster 和 redis replication + sentinal的使用場景是什么

redis replication + Sentinal:redis的一主多從,讀寫分離+哨兵機制

如果數據量很少,主要是承載高并發高性能的場景,比如緩存一般就幾個G的話,單機足夠了。那就搭建主從復制的架構(redis replication),一個mater,多個slave,要幾個slave跟你要求的讀吞吐量有關系,然后自己搭建一個sentinal集群,去保證redis主從架構的高可用性,就可以了。

而redis cluster 主要是針對海量數據+高并發+高可用的場景,如果是海量數據,如果你的數據量很大,那么建議就用redis cluster,所有master的容量總和就是redis cluster可緩存的數據容量。

redis cluster中是如何實現數據分布的?這種方式有什么優點?

redis cluster有固定的16384個hash slot(哈希槽),對每個key計算CRC16值,然后對16384取模,可以獲取key對應的hash slot。

redis cluster中每個master都會持有部分slot(槽),比如有3個master,那么可能每個master持有5000多個hash slot。

hash slot讓node的增加和移除很簡單,增加一個master,就將其他master的hash slot移動部分過去,減少一個master,就將它的hash slot移動到其他master上去。每次增加或減少master節點都是對16384取模,而不是根據master數量,這樣原本在老的master上的數據不會因master的新增或減少而找不到。并且增加或減少master時redis cluster移動hash slot的成本是非常低的。

redis cluster節點間通信是什么機制?

redis cluster節點間采取gossip協議進行通信,所有節點都持有一份元數據,不同的節點如果出現了元數據的變更之后U不斷地i將元數據發送給其他節點讓其他節點進行數據變更。

節點互相之間不斷通信,保持整個集群所有節點的數據是完整的。
主要交換故障信息、節點的增加和移除、hash slot信息等。

這種機制的好處在于,元數據的更新比較分散,不是集中在一個地方,更新請求會陸陸續續,打到所有節點上去更新,有一定的延時,降低了壓力;

缺點,元數據更新有延時,可能導致集群的一些操作會有一些滯后。

如果現在有個讀超高并發的系統,用Redis來抗住大部分讀請求,你會怎么設計?

首先,如果是讀高并發的話,先看讀并發的數量級是多少,因為redis單機的讀QPS在萬級,每秒幾萬沒問題,使用一主多從+哨兵集群的緩存架構來承載每秒10W+的讀并發,主從復制,讀寫分離。使用哨兵集群主要是提高緩存架構的可用性,解決單點故障問題。主庫負責寫,多個從庫負責讀,支持水平擴容,根據讀請求的QPS來決定加多少個redis從實例。如果讀并發繼續增加的話,只需要增加redis從實例就行了。

如果系統現在的業務量上升了,需要緩存1T+的數據,你怎么做?

因為Redis支撐海量數據的瓶頸在于單機容量,所以這個時候我會選擇redis cluster模式,每個主節點存一部分數據,假設一個master存32G,那只需要n*32G>=1T,n個這樣的master節點就可以支持1T+的海量數據的存儲了。

Redis單主的瓶頸不在于讀寫的并發,而在于內存容量,即使是一主多從也是不能解決該問題,因為一主多從架構下,多個slave的數據和master的完全一樣。假如master是10G那slave也只能存10G數據。所以數據量受單主的影響。
而這個時候又需要緩存海量數據,那就必須得有多主了,并且多個主保存的數據還不能一樣。redis官方給出的 redis cluster 模式完美的解決了這個問題。

了解什么是redis的雪崩和穿透嗎?如何應對?

其實這是問到緩存必問的,因為緩存雪崩和穿透,那是緩存最大的兩個問題,要么不出現,一旦出現就是致命性的問題。所以面試官一定會問你。

我先描述下如何出現的緩存雪崩吧。

舉個例子,假設每天高峰期的時候系統每秒請求是5000次,緩存在高峰期可以分擔每秒4000次請求,另外1000次請求落到數據庫(假設數據庫每秒可承擔2000次請求)。如果此時過來5000請求,但是redis因為某些原因掛掉了,緩存整個就不能用了,那么這5000個請求就全部落到數據庫。顯然數據庫扛不住,直接崩潰。此時,如果沒用什么特別的方案來處理這個故障,只是很著急的重啟數據庫,結果因為緩存還沒數據,立馬數據庫又被新的流量給打死了。這就是緩存雪崩。

對于緩存雪崩主要分為事前事中事后,
事前:如果緩存不可用是因為緩存中的大部分數據集中失效,我們可以對緩存的失效時間加上一個隨機值,使失效時間分散一點,盡量避免集中失效。另外如果是因為別的原因redis宕機導致緩存不可用,這時候我們就需要提前做好Redis高可用的架構,如主從+哨兵或redis cluster,來避免Redis出現故障時整個緩存不可用,全盤崩潰。

事中:可以將一小部分數據同樣緩存到本地ehcache(本地緩存組件)緩存,另外加上hystrix限流&降級組件,避免MySQL被打死。

事后:如果真的發生雪崩,我們還可以用redis的RDB或AOF重啟redis快速從磁盤加載緩存數據。這就需要我們提前打開Redis持久化機制,在雪崩發生的事后快速恢復緩存數據,一旦重啟從磁盤中恢復數據到內存。

另外一個問題,緩存穿透,一般是黑客惡意攻擊,或是自己系統出bug。例如黑客惡意偽造請求,這些請求都是數據庫根本查不到的,所以緩存中也沒用,那這些大量的惡意請求都會落到數據庫去查詢,數據庫不就掛了嗎?

解決辦法就是
1、只要從數據庫沒查到,就寫入一個空值到緩存里去。
2、使用布隆過濾器對請求的key進行一層過濾,過濾掉系統認為不存在不合法的key。

說一說redis的過期策略吧

可以參考之前的這篇文章,什么?我往Redis里寫的數據怎么沒了?

談談緩存+數據庫雙寫不一致問題

可以參考之前的這篇文章,高并發場景下緩存+數據庫雙寫不一致問題分析與解決方案設計


《【面試突擊】—Redis篇》就要結束了,暫時就整理這么多,如果你還有更多的可以告訴我來補充哦

本系列文章在于面試突擊,不是教程,要是細挖能講好多,而面試你只需要把這個原理說出來就行了,如果邊講邊畫圖那就更好了。

該系列文章在于快速突擊,快速拾遺,溫習。

posted @ 2020-01-19 14:41  為何不是夢  閱讀(472)  評論(0編輯  收藏
最新chease0ldman老人