理論修煉之Redis，分佈式緩存的中流砥柱

這是我參與8月更文挑戰的第13天，活動詳情查看：8月更文挑戰

• 📢歡迎點贊 ：👍 收藏 ⭐留言 📝 若有錯誤敬請指正，賜人玫瑰，手留餘香！
• 📢本文做者：由webmote 原創，首發於 【掘金】
• 📢做者格言： 生活在於折騰，當你不折騰生活時，生活就開始折騰你，讓咱們一塊兒加油！💪💪💪

🎏 序言

日更這個活動，初看是一種逼迫，時間久了，真的就把本身錘鍊成受虐狂了，到了時間點，總以爲要寫點啥。

天天寫寫文章，仍是蠻好玩的，梳理梳理知識體系，寫完後偶有所得的樣子，比刷抖音，刷完後索然無味的感受強多了。

此次寫寫Redis，之前的系統都是很天然的上Redis，而後後續的不少功能也是藉助Redis實現，好比分佈式鎖。

🎏 01.緩存是什麼？

這個問題來的很忽然，一時之間居然不知道怎麼回答。 其實緩存很是常見，好比咱們電腦裏的RAM，其內容斷電即丟，但少了它，即便你電腦能跑起來，那也必然是爬行的蝸牛。

固然除了RAM，還有CPU的L1和L2高速緩存，顯卡的顯存，看，緩存是多麼常見啊。

定義： 緩存就是用來加快數據請求的存儲組件，又稱做Cache。當某一對象/設備要讀取數據時，會首先從緩存中查找須要的數據，找到了則直接執行，找不到的話則從其餘慢速設備中查找。

實際上凡是位於速度相差較大的兩種設備之間，用於協調二者數據傳輸速度差的結構，都可以成爲廣義的緩存。

緩存並不僅是放在內存，好比SSD硬盤的在某些場景下也能夠做爲緩存的存儲介質。

🎏 01.1 經常使用硬件讀寫量級

那麼問題來了，咱們經常使用的硬件，它們的讀寫速度都是什麼量級的呢？

借用專家的圖，來看看，務必在腦海中有這個印象哦。

🎏 01.2 與緩衝區的區別

如下觀點屬於程老大，無節操默寫。

易混淆概念，緩衝區（buffer）：系統兩端處理速度平衡（從長時間尺度上看）時使用的。它的引入是爲了減少短時間內突發I/O的影響，起到流量整形的做用。好比生產者——消費者問題，他們產生和消耗資源的速度大致接近，加一個buffer能夠抵消掉資源剛產生/消耗時的忽然變化峯值。

Cache（緩存）: 則是系統兩端處理速度不匹配時的一種折衷策略。由於CPU和memory之間的速度差別愈來愈大，因此人們充分利用數據的局部性（locality）特徵，經過使用存儲系統分級（memory hierarchy）的策略來減少這種差別帶來的影響。

🎏 01.3 常見分類

緩存的常見分類有靜態緩存、分佈式緩存和本地緩存。

• 靜態緩存，好比動態頁面靜態化，能夠很容易進行CDN化頂住大流量；
• 分佈式緩存：處於網絡遠端，經過分佈式集羣能夠擴展緩存性能的組件。
• 本地緩存：通常是本地的內存，其速度優於分佈式緩存，不須要跨越網絡，通常用於短時熱點緩存。

🎏 01.4 應用場景

緩存這麼好，能解決全部問題嗎？

想啥呢？緩存不能解決全部問題。

• 緩存最適合讀多寫少，帶熱點的場景；
• 緩存帶來了複雜度，而且有數據不一致的風險；
• 緩存通常使用內存，其容量相比硬盤差了好幾個量級；

引入緩存需謹慎設計讀寫方案，以免這些問題。

🎏 02 經常使用緩存讀寫機制以及數據一致性問題

• Cache Aside
• Read Through/Write Through
• Write Behind Caching

🎏 02.1 Cache Aside

讀數據：先讀緩存，若是沒有命中緩存，則讀取數據庫，若是命中，則直接返回緩存

寫數據：先更新數據庫，再刪除緩存

該模式在開發中最經常使用，須要咱們熟練掌握。 固然其並不完美，咱們知道在分佈式系統中，想徹底保證數據一致性是極爲困難的事情。 極端狀況以下：

🎏 02.2 Read Through/Write Through

引入了緩存組件。

讀數據：先讀緩存，若是沒有命中緩存，則有緩存組件讀取數據庫並加載緩存，若是命中，則直接返回緩存

寫數據：查詢緩存是否命中，若是命中，則更新緩存，並由緩存組件同步到數據庫，不然，由緩存組件直接寫數據庫

因爲寫數據時，同步寫數據庫，所以，速度上會有影響，這種模式並不常見，由於引入了緩存組件，增長了複雜度。

🎏 02.3 Write Behind Caching

這種模式一般是先將數據寫入緩存，再異步寫入數據庫。其優點是增長了吞吐量，劣勢也很明顯，若是發生宕機，則由丟失數據風險。

03. Redis 支持的類型

這裏只作羅列，並不細講，相關文章太多了，本身搜搜參考吧。

Redis支持多種數據類型：string，hash，list，set、zset、Bitmap、HyperLogLogs、Streams。

Redis具備發佈訂閱消息功能，利用最新的數據類型Streams，聽說能夠作到很是強大的消息隊列功能，以前看過一篇文章，有興趣的能夠搜搜。

04. Redis 過時時間和策略

Redis支持不少方式設置一個key的過時時間，過時的Key咱們是讀取不到數據的，然而這個Key在服務器上還佔空間嗎？

默認狀況下，是不清理內存佔用的。

Redis有不少種內存淘汰機制，默認採用的是 noeviction。

• noeviction:默認策略，不淘汰，若是內存已滿，添加數據就報錯；
• allkeys-lru:在全部鍵範圍，選取最近使用頻率最低的數據拋棄；
• allkeys-random: 在全部鍵範圍，隨機拋棄；
• volatile-lru:在設置了過時時間的全部鍵中，選取最近使用頻率最低的數據拋棄；
• volatile-ttl:在設置了過時時間的全部鍵，存活時間最短的數據拋棄；
• volatile-random: 在設置了過時時間的全部鍵，隨機拋棄；

刪除鍵不是一個小活，所以能夠搭配定時刪除和惰性刪除相結合的方式進行。

05. Redis 高可用

Redis Sentinel 爲Redis提供高可用。這意味着使用 Sentinel，您能夠建立一個 Redis 部署，無需人工干預便可抵抗某些故障。

Sentinel 功能：

• 監控，Sentinel 會不斷檢查您的主節點和副本節點是否按預期工做。
• 通知，Sentinel 能夠經過 API 通知系統管理員或其餘計算機程序，其中一個受監控的 Redis 實例出現問題。
• 自動故障轉移，若是 master 沒有按預期工做，Sentinel 能夠啓動一個故障轉移過程，其中一個副本被提高爲 master，其餘額外的副本被從新配置爲使用新的 master，而且使用 Redis 服務器的應用程序會被告知要使用的新地址鏈接。
• 配置提供程序，Sentinel 充當客戶端服務發現的權威來源：客戶端鏈接到 Sentinel 以請求負責給定服務的當前 Redis 主節點的地址。若是發生故障轉移，Sentinels 將報告新地址。

🎏 06. 小結

其實還有不少內容，我想寫的更多，但是實力和時間不容許，暫時到這吧，後續有什麼不妥的還能夠修改追加，感謝你看到這裏！

例行小結，理性看待！

結的是啥啊，結的是我想你點贊而不可得的寂寞。😳😳😳

👓都看到這了，還在意點個贊嗎？

👓都點讚了，還在意一個收藏嗎？

👓都收藏了，還在意一個評論嗎？