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

時間 2020-05-26

標籤【面試突擊】— Redis篇 redis cluster 緩存使用架構設計常見問題欄目 Redis 简体版

原文原文鏈接

能堅持別人不能堅持的，才能擁有別人不曾擁有的。
關注編程大道公衆號，讓咱們一同堅持心中所想，一塊兒成長！！html

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

在這個系列裏，我會整理一些面試題與你們分享，幫助年後和我同樣想要在金三銀四準備跳槽的同窗。
咱們一塊兒鞏固、突擊面試官常問的一些面試題，加油！！面試

《【面試突擊】— Redis篇》--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複製+主從架構+讀寫分離+哨兵集羣+高可用，不須要這樣去搭了。app

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。例如黑客惡意僞造請求，這些請求都是數據庫根本查不到的，因此緩存中也沒用，那這些大量的惡意請求都會落到數據庫去查詢，數據庫不就掛了嗎？

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