Redis Cluster常見(jiàn)面試題有哪些

說(shuō)說(shuō)Redis cluster

在redis cluster集群架構(gòu)中，可以由N個(gè)redis master node組成，每個(gè)master node都可以掛載多個(gè)slave node。
可以自動(dòng)將數(shù)據(jù)進(jìn)行分片，每個(gè)master上放一部分?jǐn)?shù)據(jù)；
還提供內(nèi)置的高可用支持，部分master不可用時(shí)，還是可以繼續(xù)工作的，因?yàn)槊總€(gè)master都有salve節(jié)點(diǎn)，那么如果mater掛掉，redis cluster這套機(jī)制，就會(huì)自動(dòng)將某個(gè)slave切換成master；
支持讀寫分離：對(duì)于每個(gè)master來(lái)說(shuō)，都負(fù)責(zé)寫請(qǐng)求，寫就寫到master，然后讀就從mater對(duì)應(yīng)的slave去讀；

總結(jié)：redis cluster（多master + 讀寫分離 + 高可用）

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

redis cluster 和 redis replication + sentinal的使用場(chǎng)景是什么

redis replication + Sentinal：redis的一主多從，讀寫分離+哨兵機(jī)制

如果數(shù)據(jù)量很少，主要是承載高并發(fā)高性能的場(chǎng)景，比如緩存一般就幾個(gè)G的話，單機(jī)足夠了。那就搭建主從復(fù)制的架構(gòu)（redis replication），一個(gè)mater，多個(gè)slave，要幾個(gè)slave跟你要求的讀吞吐量有關(guān)系，然后自己搭建一個(gè)sentinal集群，去保證redis主從架構(gòu)的高可用性，就可以了。

而redis cluster 主要是針對(duì)海量數(shù)據(jù)+高并發(fā)+高可用的場(chǎng)景，如果是海量數(shù)據(jù)，如果你的數(shù)據(jù)量很大，那么建議就用redis cluster。

redis cluster是如何實(shí)現(xiàn)數(shù)據(jù)分布的？這種方式有什么優(yōu)點(diǎn)？

redis cluster有固定的16384個(gè)hash slot（哈希槽），對(duì)每個(gè)key計(jì)算CRC16值，然后對(duì)16384取模，可以獲取key對(duì)應(yīng)的hash slot。

redis cluster中每個(gè)master都會(huì)持有部分slot（槽），比如有3個(gè)master，那么可能每個(gè)master持有5000多個(gè)hash slot。

hash slot讓node的增加和移除很簡(jiǎn)單，增加一個(gè)master，就將其他master的hash slot移動(dòng)部分過(guò)去，減少一個(gè)master，就將它的hash slot移動(dòng)到其他master上去。每次增加或減少master節(jié)點(diǎn)都是對(duì)16384取模，而不是根據(jù)master數(shù)量，這樣原本在老的master上的數(shù)據(jù)不會(huì)因master的新增或減少而找不到。并且增加或減少master時(shí)redis cluster移動(dòng)hash slot的成本是非常低的。

redis cluster節(jié)點(diǎn)間通信是什么機(jī)制？

redis cluster節(jié)點(diǎn)間采取gossip協(xié)議進(jìn)行通信，所有節(jié)點(diǎn)都持有iFeng元數(shù)據(jù)，不同的節(jié)點(diǎn)如果出現(xiàn)了元數(shù)據(jù)的變更之后U不斷地i將元數(shù)據(jù)發(fā)送給其他節(jié)點(diǎn)讓其他節(jié)點(diǎn)進(jìn)行數(shù)據(jù)變更。

節(jié)點(diǎn)互相之間不斷通信，保持整個(gè)集群所有節(jié)點(diǎn)的數(shù)據(jù)是完整的。
主要交換故障信息、節(jié)點(diǎn)的增加和移除、hash slot信息等。

這種機(jī)制的好處在于，元數(shù)據(jù)的更新比較分散，不是集中在一個(gè)地方，更新請(qǐng)求會(huì)陸陸續(xù)續(xù)，打到所有節(jié)點(diǎn)上去更新，有一定的延時(shí)，降低了壓力;

缺點(diǎn)，元數(shù)據(jù)更新有延時(shí)，可能導(dǎo)致集群的一些操作會(huì)有一些滯后。

如果現(xiàn)在有個(gè)讀超高并發(fā)的系統(tǒng)，用Redis來(lái)抗住大部分讀請(qǐng)求，你會(huì)怎么設(shè)計(jì)？

首先，如果是讀高并發(fā)的話，先看讀并發(fā)的數(shù)量級(jí)是多少，因?yàn)閞edis單機(jī)的讀QPS在萬(wàn)級(jí)，每秒幾萬(wàn)沒(méi)問(wèn)題，使用一主多從+哨兵集群的緩存架構(gòu)來(lái)承載每秒10W+的讀并發(fā)，主從復(fù)制，讀寫分離。使用哨兵集群主要是提高緩存架構(gòu)的可用性，解決單點(diǎn)故障問(wèn)題。主庫(kù)負(fù)責(zé)寫，多個(gè)從庫(kù)負(fù)責(zé)讀，支持水平擴(kuò)容，根據(jù)讀請(qǐng)求的QPS來(lái)決定加多少個(gè)redis從實(shí)例。如果讀并發(fā)繼續(xù)增加的話，只需要增加redis從實(shí)例就行了。

如果系統(tǒng)現(xiàn)在的業(yè)務(wù)量上升了，需要緩存1T+的數(shù)據(jù)，你怎么做？

因?yàn)镽edis支撐海量數(shù)據(jù)的瓶頸在于單機(jī)容量，所以這個(gè)時(shí)候我會(huì)選擇redis cluster模式，每個(gè)主節(jié)點(diǎn)存一部分?jǐn)?shù)據(jù)，假設(shè)一個(gè)master存32G，那只需要n*32G>=1T，n個(gè)這樣的master節(jié)點(diǎn)就可以支持1T+的海量數(shù)據(jù)的存儲(chǔ)了。

Redis單主的瓶頸不在于讀寫的并發(fā)，而在于內(nèi)存容量，即使是一主多從也是不能解決該問(wèn)題，因?yàn)橐恢鞫鄰募軜?gòu)下，多個(gè)slave的數(shù)據(jù)和master的完全一樣。假如master是10G那slave也只能存10G數(shù)據(jù)。所以數(shù)據(jù)量受單主的影響。
而這個(gè)時(shí)候又需要緩存海量數(shù)據(jù)，那就必須得有多主了，并且多個(gè)主保存的數(shù)據(jù)還不能一樣。redis官方給出的 redis cluster 模式完美的解決了這個(gè)問(wèn)題。

了解什么是redis的雪崩和穿透嗎？如何應(yīng)對(duì)？

其實(shí)這是問(wèn)到緩存必問(wèn)的，因?yàn)榫彺嫜┍篮痛┩?，那是緩存最大的兩個(gè)問(wèn)題，要么不出現(xiàn)，一旦出現(xiàn)就是致命性的問(wèn)題。所以面試官一定會(huì)問(wèn)你。

我先描述下如何出現(xiàn)的緩存雪崩吧。

舉個(gè)例子，假設(shè)每天高峰期的時(shí)候系統(tǒng)每秒請(qǐng)求是5000次，緩存在高峰期可以分擔(dān)每秒4000次請(qǐng)求，另外1000次請(qǐng)求落到數(shù)據(jù)庫(kù)（假設(shè)數(shù)據(jù)庫(kù)每秒可承擔(dān)2000次請(qǐng)求）。如果此時(shí)過(guò)來(lái)5000請(qǐng)求，但是redis因?yàn)槟承┰驋斓袅?，緩存整個(gè)就不能用了，那么這5000個(gè)請(qǐng)求就全部落到數(shù)據(jù)庫(kù)。顯然數(shù)據(jù)庫(kù)扛不住，直接崩潰。此時(shí)，如果沒(méi)用什么特別的方案來(lái)處理這個(gè)故障，只是很著急的重啟數(shù)據(jù)庫(kù)，結(jié)果因?yàn)榫彺孢€沒(méi)數(shù)據(jù)，立馬數(shù)據(jù)庫(kù)又被新的流量給打死了。這就是緩存雪崩。

對(duì)于緩存雪崩主要分為事前事中事后，
事前：如果緩存不可用是因?yàn)榫彺嬷械拇蟛糠謹(jǐn)?shù)據(jù)集中失效，我們可以對(duì)緩存的失效時(shí)間加上一個(gè)隨機(jī)值，使失效時(shí)間分散一點(diǎn)，盡量避免集中失效。另外如果是因?yàn)閯e的原因redis宕機(jī)導(dǎo)致緩存不可用，這時(shí)候我們就需要提前做好Redis高可用的架構(gòu)，如主從+哨兵或redis cluster，來(lái)避免Redis出現(xiàn)故障時(shí)整個(gè)緩存不可用，全盤崩潰。

事中：可以將一小部分?jǐn)?shù)據(jù)同樣緩存到本地ehcache（本地緩存組件）緩存，另外加上hystrix限流&降級(jí)組件，避免MySQL被打死。

事后：如果真的發(fā)生雪崩，我們還可以用redis的RDB或AOF重啟redis快速?gòu)拇疟P加載緩存數(shù)據(jù)。這就需要我們提前打開(kāi)Redis持久化機(jī)制，在雪崩發(fā)生的事后快速恢復(fù)緩存數(shù)據(jù)，一旦重啟從磁盤中恢復(fù)數(shù)據(jù)到內(nèi)存。

另外一個(gè)問(wèn)題，緩存穿透，一般是黑客惡意攻擊，或是自己系統(tǒng)出bug。例如黑客惡意偽造請(qǐng)求，這些請(qǐng)求都是數(shù)據(jù)庫(kù)根本查不到的，所以緩存中也沒(méi)用，那這些大量的惡意請(qǐng)求都會(huì)落到數(shù)據(jù)庫(kù)去查詢，數(shù)據(jù)庫(kù)不就掛了嗎？

解決辦法就是
1、只要從數(shù)據(jù)庫(kù)沒(méi)查到，就寫入一個(gè)空值到緩存里去。
2、使用布隆過(guò)濾器對(duì)請(qǐng)求的key進(jìn)行一層過(guò)濾，過(guò)濾掉系統(tǒng)認(rèn)為不存在不合法的key。