一.什麼是哨兵機制?
答：Redis的哨兵(sentinel) 系統用於管理多個 Redis 服務器,該系統執行以下三個任務:
監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
提醒(Notification):當被監控的某個 Redis出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。
自動故障遷移(Automatic failover):當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級爲新的Master, 並讓失效Master的其他Slave改爲複製新的Master; 當客戶端試圖連接失效的Master時,集羣也會向客戶端返回新Master的地址,使得集羣可以使用Master代替失效Master。
哨兵(sentinel) 是一個分佈式系統,你可以在一個架構中運行多個哨兵(sentinel) 進程,這些進程使用流言協議(gossipprotocols)來接收關於Master是否下線的信息,並使用投票協議(agreement protocols)來決定是否執行自動故障遷移,以及選擇哪個Slave作爲新的Master。
每個哨兵(sentinel) 會向其它哨兵(sentinel)、master、slave定時發送消息,以確認對方是否”活”着,如果發現對方在指定時間(可配置)內未迴應,則暫時認爲對方已掛(所謂的”主觀認爲宕機” Subjective Down,簡稱sdown).
若“哨兵羣”中的多數sentinel,都報告某一master沒響應,系統才認爲該master"徹底死亡"(即:客觀上的真正down機,Objective Down,簡稱odown),通過一定的vote算法,從剩下的slave節點中,選一臺提升爲master,然後自動修改相關配置。
雖然哨兵(sentinel) 釋出爲一個單獨的可執行文件 redis-sentinel ,但實際上它只是一個運行在特殊模式下的 Redis 服務器，你可以在啓動一個普通 Redis 服務器時通過給定 --sentinel 選項來啓動哨兵(sentinel)。
哨兵(sentinel) 的一些設計思路和zookeeper非常類似
其實整個過程只需要一個哨兵節點來完成，首先使用Raft算法（感興趣的同學可以查一下，其實就是個選舉算法）實現選舉機制，選出一個哨兵節點來完成轉移和通知
哨兵有三個定時監控任務完成對各節點的發現和監控：
任務1，每個哨兵節點每10秒會向主節點和從節點發送info命令獲取最拓撲結構圖，哨兵配置時只要配置對主節點的監控即可，通過向主節點發送info，獲取從節點的信息，並當有新的從節點加入時可以馬上感知到
任務2，每個哨兵節點每隔2秒會向redis數據節點的指定頻道上發送該哨兵節點對於主節點的判斷以及當前哨兵節點的信息，同時每個哨兵節點也會訂閱該頻道，來了解其它哨兵節點的信息及對主節點的判斷，其實就是通過消息publish和subscribe來完成的；
任務3，每隔1秒每個哨兵會向主節點、從節點及其餘哨兵節點發送一次ping命令做一次心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據
主觀下線和客觀下線：
主觀下線：剛知道哨兵節點每隔1秒對主節點和從節點、其它哨兵節點發送ping做心跳檢測，當這些心跳檢測時間超過down-after-milliseconds時，哨兵節點則認爲該節點錯誤或下線，這叫主觀下線；這可能會存在錯誤的判斷。
客觀下線：當主觀下線的節點是主節點時，此時該哨兵3節點會通過指令sentinel is-masterdown-by-addr尋求其它哨兵節點對主節點的判斷，當超過quorum（法定人數）個數，此時哨兵節點則認爲該主節點確實有問題，這樣就客觀下線了，大部分哨兵節點都同意下線操作，也就說是客觀下線
領導者哨兵選舉流程：
a,每個在線的哨兵節點都可以成爲領導者，當它確認（比如哨兵3）主節點下線時，會向其它哨兵發is-master-down-by-addr命令，徵求判斷並要求將自己設置爲領導者，由領導者處理故障轉移；
b,當其它哨兵收到此命令時，可以同意或者拒絕它成爲領導者；
c,如果哨兵3發現自己在選舉的票數大於等於num(sentinels)/2+1時，將成爲領導者，如果沒有超過，繼續選舉…………
故障轉移機制
A，由Sentinel節點定期監控發現主節點是否出現了故障
sentinel會向master發送心跳PING來確認master是否存活，如果master在“一定時間範圍”內不迴應PONG 或者是回覆了一個錯誤消息，那麼這個sentinel會主觀地(單方面地)認爲這個master已經不可用了
B，當主節點出現故障，此時3個Sentinel節點共同選舉了Sentinel3節點爲領導，負載處理主節點的故障轉移,
C，由Sentinel3領導者節點執行故障轉移，過程和主從複製一樣，但是自動執行
流程： 1，將slave-1脫離原從節點，升級主節點，
2，將從節點slave-2指向新的主節點
3，通知客戶端主節點已更換
4，將原主節點（oldMaster）變成從節點，指向新的主節點
D，故障轉移後的redis sentinel的拓撲結構圖
哨兵機制－故障轉移詳細流程
A，過濾掉不健康的（下線或斷線），沒有回覆過哨兵ping響應的從節點
B，選擇salve-priority從節點優先級最高（redis.conf）
C，選擇複製偏移量最大，指複製最完整的從節點
哨兵sentinel個數爲奇數，選舉嘛，奇數哨兵個才能選舉成功，一般建議3個
注意： redis集羣（採用虛擬槽方式，高可用）原理（和哨兵模式原理類似，3.0版本或以上纔有）
二、Redis常考的面試題：
1. 緩存更新策略（即如何讓緩存和mysql保持一致性）？
2. key過期清除（超時剔除）策略
惰性過期（類比懶加載，這是懶過期）：只有當訪問一個key時，纔會判斷該key是否已過期，過期則清除。該策略可以最大化地節省CPU資源，卻對內存非常不友好。極端情況可能出現大量的過期key沒有再次被訪問，從而不會被清除，佔用大量內存。
定期過期：每隔一定的時間，會掃描一定數量的數據庫的expires字典中一定數量的key，並清除其中已過期的key。該策略是前兩者的一個折中方案。通過調整定時掃描的時間間隔和每次掃描的限定耗時，可以在不同情況下使得CPU和內存資源達到最優的平衡效果。
(expires字典會保存所有設置了過期時間的key的過期時間數據，其中，key是指向鍵空間中的某個鍵的指針，value是該鍵的毫秒精度的UNIX時間戳表示的過期時間。鍵空間是指該Redis集羣中保存的所有鍵。)
問：比如這麼個場景，我設計了很多key，過期時間是5分鐘，當前內存佔用率是50%。但是5分鐘到了，內存佔用率還是很高，請問爲什麼？
Redis中同時使用了惰性過期和定期過期兩種過期策略，即使過期時間到了，但是有部分並沒有真正刪除，等待惰性刪除。
爲什麼有定期還要有惰性呢？其實很簡單，比如10萬個key就要過期了，Redis默認是100ms檢查一波。如果他檢查出10萬個即將要清除，那他接下來的時間基本都是在幹這些清空內存的事了，那肯定影響性能，所以他只會部分刪除，剩下的等惰性
3. Redis的內存淘汰策略
Redis的內存淘汰策略是指在Redis的用於緩存的內存不足時，怎麼處理需要新寫入且需要申請額外空間的數據。
noeviction：當內存不足以容納新寫入數據時，新寫入操作會報錯。
allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的key。
allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個key。
volatile-lru：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，移除最近最少使用的key。
volatile-random：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，隨機移除某個key。
volatile-ttl：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，有更早過期時間的key優先移除。
4. 緩存粒度控制？
5. 如何防止緩存穿透？
（緩存穿透指的是查詢一個根本不存在的數據，緩存層不命中，又去查存儲層，又不命中。但如果有大量這種查詢不存在的數據的請求過來，會對存儲層有較大壓力，若是惡意×××，後果就）
緩存空值存在的問題：
布隆過濾器：
布隆過濾器存在的問題：相對來說布隆過濾器搞起來代碼還是比較複雜的，現階段我們暫時還不需要，後面實在需要再考慮去做，什麼階段做什麼樣的事情，不是說這個系統一下子就能做的各種完美。
6. 無底洞優化？
造成原因：redis分佈式越來越多，導致性能反而下降，因爲鍵值分佈到更多的 節點上，所以無論是Memcache還是Redis的分佈式，批量操作通常需要從不 同節點上獲取，相比於單機批量操作只涉及一次網絡操作，分佈式批量操作 會涉及多次網絡時間。 即分佈式過猶不及。
7. 雪崩優化
如果緩存層由於某些原因不能提供服務，於是所有的請求都會達到存儲層，存儲層的調用量會暴增，造成存儲層也會級聯宕機的情況。
8. 熱點key優化
當前key是一個熱點key（例如一個熱門的娛樂新聞），併發量非常大。
參考： https://blog.csdn.net/yswKnight/article/details/78158540
https://blog.51cto.com/13883927/2156957