《終章》後端分佈式多級緩存架構，也許你一直考慮的太簡單了

這篇想聊的話題是:分佈式多級緩存架構的終章，如何解決大流量、高併發這樣的業務場景，取決於你能不能成爲這個領域金字塔上層的高手? 能不能把這個問題思考清楚決定了你的成長速度。

不少人在一個行業5年、10年，依然未達到這個行業的中層甚至還停留在底層，由於他們歷來不關心這樣的話題。做爲砥礪前行的踐行者，我以爲有必要給你們來分享一下。

開篇

服務端緩存是整個緩存體系中的重頭戲，從開始的網站架構演進中，想必你已看到服務端緩存在系統性能的重要性。

但數據庫確是整個系統中的「半吊子|慢性子」，有時數據庫調優卻可以以小搏大，在不改變架構和代碼邏輯的前提下，緩存參數的調整每每是條捷徑。

在系統開發的過程當中，可直接在平臺側使用緩存框架，當緩存框架沒法知足系統對性能的要求時，就須要在應用層自主開發應用級緩存。

緩存經常使用的就是Redis這東西，那到底什麼是平臺級、應用級緩存呢？

後面給你們揭曉。但有一點可代表，平臺級就是你所選擇什麼開發語言來實現緩存，而應用級緩存，則是經過應用程序來達到目的。

01數據庫緩存

爲什麼說數據庫是「慢性子」呢？ 對如今喜歡 快的你來講，慢是解決不了問題的。就好像總感受感受妹子回覆慢

由於數據庫屬於IO密集型應用，主要負責數據的管理及存儲。數據一多查詢自己就有可能變慢， 這也是爲啥數據上得了檯面時，查詢愛用索引提速的緣由。固然數據庫自身也有「緩存」來解決這個問題。

數據多了查詢不該該都慢嗎？ 小白說吒吒輝你不懂額

。。。這個，你說的也不全是，還得分狀況。例如：數據有上億行

緣由：

1. 由於簡單的SQL的結果不會特別多。你請求也不大，磁盤跟的上
2. 併發總量超過磁盤吞吐上限，是誰都沒招

就算大家不喜歡吒吒輝，我也要奮筆疾書

數據庫緩存是自身一類特殊的緩存機制。大多數數據庫不須要配置就能夠快速運行，但並無爲特定的需求進行優化。在數據庫調優的時候，緩存優化你能夠考慮下。

以MySQL爲例，MySQL中使用了查詢緩衝機制，將SELECT語句和查詢結果存放在緩衝區中，以鍵值對的形式存儲。之後對於一樣的SELECT語句，將直接從緩衝區中讀取結果，以節省查詢時間，提升了SQL查詢的效率。

1.1.MySQL查詢緩存

Query cache做用於整個MySQL實例，主要用於緩存MySQL中的ResultSet，也就是一條SQL語句執行的結果集，因此它只針對select語句。

當打開 Query Cache 功能，MySQL在接收到一條select語句的請求後，若是該語句知足Query Cache的條件，MySQL會直接根據預先設定好的HASH算法將接收到的select語句以字符串方式進行 hash，而後到Query Cache中直接查找是否已經緩存。

若是結果集已經在緩存中，該select請求就會直接將數據返回，從而省略後面全部的步驟（如SQL語句的解析，優化器優化以及向存儲引擎請求數據等），從而極大地提升了性能。

固然，若數據變化很是頻繁的狀況下，使用Query Cache可能會得不償失。

這是爲啥，用它不是提速嗎？咋還得不償失

由於MySQL只要涉及到數據更改，就會從新維護緩存。

1. 若是SQL請求量比較大，你在維護的時候，就透過緩存走磁盤檢索。這樣數據庫的壓力確定大。
2. 重建緩存數據，它須要mysql後臺線程來工做。也會增長數據庫的負載。

因此在MySQL8已經取消了它。 故通常在讀多寫少，數據不怎麼變化的場景可用它，例如：博客

Query Cache使用須要多個參數配合，其中最爲關鍵的是query_cache_size和query_cache_type， 前者用於設置緩存ResultSet的內存大小，後者設置在何種場景下使用Query Cache。

這樣能夠經過計算Query Cache的命中率來進行調整緩存大小。

1.2.檢驗Query Cache的合理性

檢查Query Cache設置的是否合理，能夠經過在MySQL控制檯執行如下命令觀察：

• SHOW VARIABLES LIKE '%query_cache%';

• SHOW STATUS LIKE 'Qcache%'; 經過檢查如下幾個參數能夠知道query_cache_size設置得是否合理：

  • Qcache_inserts：表示Cache多少次未命中而後插入到緩存
  • Qcache_hits: 表示命中多少次，它可反映出緩存的使用效果。

若是Qcache_hits的值很是大，則代表查詢緩衝使用很是頻繁，若是該值較小反而會影響效率，那麼能夠考慮不用查詢緩存；

• Qcache_lowmem_prunes: 表示多少條Query由於內存不足而被清除出Query_Cache。

若是Qcache_lowmem_prunes的值很是大，則代表常常出現緩衝不夠的狀況，因增長緩存容量。

• Qcache_free_blocks： 表示緩存區的碎片

Qcache_free_blocks值很是大，則代表緩存區中的碎片不少，可能須要尋找合適的機會進行整理。

經過 Qcache_hits 和 Qcache_inserts 兩個參數能夠算出Query Cache的命中率：

經過 Qcache_lowmem_prunes 和 Qcache_free_memory 相互結合，能更清楚地瞭解到系統中Query Cache的內存大小是否真的足夠，是否頻繁的出現因內存不足而有Query被換出的狀況。

1.3.InnoDB的緩存性能

當選擇 InnoDB 時，innodb_buffer_pool_size 參數多是影響性能的最爲關鍵的一個參數，它用來設置緩存InnoDB索引及數據塊、自適應HASH、寫緩衝等內存區域大小，更像是Oracle數據庫的 db_cache_size。

簡單來講，當操做InnoDB表的時候，返回的全部數據或者查詢過程當中用到的任何一個索引塊，都會在這個內存區域中去查詢一遍。

和MyISAM引擎中的 key_buffer_size 同樣，innodb_buffer_pool_size設置了 InnoDB 引擎需求最大的一塊內存區域，直接關係到InnoDB存儲引擎的性能，因此若是有足夠的內存，儘可將該參數設置到足夠大，將盡量多的InnoDB的索引及數據都放入到該緩存區域中，直至所有。

說到緩存確定少不了，緩存命中率。那innodb該如何計算？

計算出緩存命中率後，在根據命中率來對
`
innodb_buffer_pool_size 參數大小進行優化`

除開查詢緩存。數據庫查詢的性能也與MySQL的鏈接數有關

table_cache 用於設置 table 高速緩存的數量。

show global status like 'open%_tables'; # 查看參數

因爲每一個客戶端鏈接都會至少訪問一個表，所以該參數與max_connections有關。當某一鏈接訪問一個表時，MySQL會檢查當前已緩存表的數量。

若是該表已經在緩存中打開，則會直接訪問緩存中的表以加快查詢速度；若是該表未被緩存，則會將當前的表添加進緩存在進行查詢。

在執行緩存操做以前，table_cache參數用於限制緩存表的最大數目：

若是當前已經緩存的表未達到table_cache數目，則會將新表添加進來；若已經達到此值，MySQL將根據緩存表的最後查詢時間、查詢率等規則釋放以前的緩存。

02平臺級緩存

什麼是平臺級緩存，說的這個玄乎？

平臺級緩存是指你所用什麼開發語言，具體選擇的是那個平臺，畢竟緩存自己就是提供給上層調用。主要針對帶有緩存特性的應用框架，或者可用於緩存功能的專用庫。

如：

• PHP中的Smarty模板庫
• Java中，緩存框架更多，如Ehcache，Cacheonix，Voldemort，JBoss Cache，OSCache等等。

Ehcache是如今最流行的純Java開源緩存框架，配置簡單、結構清晰、功能強大，是從hibernate的緩存開始被普遍使用起來的。EhCache有以下特色：

Ehcache的系統結構如圖所示:

什麼是分佈式緩存呢？好像我還沒搞明白，小吒哥

首先得看看恆古不變的「分佈式」，即它是獨立的部署到多個服務節點上或者獨立的進程，彼此之間僅僅經過消息傳遞進行通訊和協調。

也就是說分佈式緩存，它要麼是在單機上有多個實例，要麼就獨立的部署到不一樣服務器，從而把緩存分散到各處

最後經過客戶端鏈接到對應的節點來進行緩存操做。

Voldemort是一款基於Java開發的分佈式鍵-值緩存系統，像JBoss的緩存同樣，Voldemort一樣支持多臺服務器之間的緩存同步，以加強系統的可靠性和讀取性能。

Voldemort有以下特色：

Voldemort的邏輯架構圖

Voldemort至關因而Amazon Dynamo的一個開源實現，LinkedIn用它解決了網站的高擴展性存儲問題。

簡單來講，就平臺級緩存而言，只須要在框架側配置一下屬性便可，而不須要調用特定的方法或函數。

系統中引入緩存技術每每就是從平臺級緩存開始，平臺級緩存也一般會做爲一級緩存使用。

既然平臺級緩存都使用框架配置來實現，這咋實現緩存的分佈式呢？節點之間都沒有互相的消息通信了

若是單看，框架緩存的調用，那確實沒辦法作到分佈式緩存，由於自身沒得像Redis那樣分佈式的部署方式，經過網絡把各節點鏈接 。
但本地平臺緩存可經過遠程過程調用，來操做分佈在各個節點上的平臺緩存數據。

在 Ehcache 中：

03應用級緩存

當平臺級緩存不能知足系統的性能時，就要考慮使用應用級緩存。 應用級緩存，須要開發者經過代碼來實現緩存機制。

有些許 一方有難，八方支援 的感受。本身搞不定 ，請教別人

這是NoSQL的戰場，不管是Redis仍是MongoDB，以及Memcached均可做爲應用級緩存的技術支持。
一種典型的方式是每分鐘或一段時間後統一輩子成某類頁面存儲在緩存中，或者能夠在熱數據變化時更新緩存。

爲啥平臺緩存還不能知足系統性能要求呢？它不是還能夠減小應用緩存的網絡開銷嗎
那你得看這幾點：

3.1面向Redis的緩存應用

Redis是一款開源的、基於BSD許可的高級鍵值對緩存和存儲系統，例如：新浪微博有着幾乎世界上最大的Redis集羣。

爲什麼新浪微博是世界上最大的Redis集羣呢？

微博是一個社交平臺，其中用戶關注與被關注、微博熱搜榜、點擊量、高可用、緩存穿透等業務場景和技術問題。Redis都有對應的hash、ZSet、bitmap、cluster等技術方案來解決。

在這種數據關係複雜、易變化的場景上面用到它會顯得很簡單。好比：

用戶關注與取消：用hash就能夠很方便的維護用戶列表，你能夠直接找到key,而後更改value裏面的關注用戶便可。

若是你像 memcache ，那隻能先序列化好用戶關注列表存儲，更改在反序列化。而後再緩存起來，像大V有幾百萬、上千萬的用戶，一旦關注/取消。
當前任務的操做就會有延遲。

Reddis主要功能特色

• 主從同步

Redis支持主從同步，數據能夠從主服務器向任意數量的從服務器同步，從服務器可作爲關聯其餘從服務器的主服務器。這使得Redis可執行單層樹狀複製。

• 發佈/訂閱

因爲實現了發佈/訂閱機制，使得從服務器在任何地方同步樹的時候，可訂閱一個頻道並接收主服務器完整的消息發佈記錄。同步對讀取操做的可擴展性和數據冗餘頗有幫助。

• 集羣

Redis 3.0版本加入cluster功能，解決了Redis單點沒法橫向擴展的問題。Redis集羣採用無中心節點方式實現，無需proxy代理，客戶端直接與Redis集羣的每一個節點鏈接，根據一樣的哈希算法計算出key對應的slot，而後直接在slot對應的Redis上執行命令。

從Redis視角來看，響應時間是最苛刻的條件，增長一層帶來的開銷是不能接受的。所以，Redis實現了客戶端對節點的直接訪問，爲了去中心化，節點之間經過Gossip協議交換相互的狀態，以及探測新加入的節點信息。Redis集羣支持動態加入節點，動態遷移slot，以及自動故障轉移。

Redis集羣的架構示意如圖所示。

那什麼是 Gossip 協議呢？ 感受好高大上，各類協議頻繁出現

Gossip 協議是一個多播協議，基本思想是：
一個節點想要分享一些信息給網絡中的其餘的一些節點。因而，它週期性的隨機選擇一些節點，並把信息傳遞給這些節點。這些收到信息的節點接下來會作一樣的事情，即把這些信息傳遞給其餘一些隨機選擇的節點。直至所有的節點。

即，Redis集羣中添加、剔除、選舉主節點，都是基於這樣的方式。

例如：當加入新節點時(meet)，集羣中會隨機選擇一個節點來邀請新節點，此時只有邀請節點和被邀請節點知道這件事，其他節點要等待 ping 消息一層一層擴散。
除了 Fail 是當即全網通知的，其餘諸如新節點、節點重上線、從節點選舉成爲主節點、槽變化等，都須要等待被通知到，因此Gossip協議也是最終一致性的協議。

這種多播的方式，是否是突然有種好事不出門，壞事傳千里的感腳

然而，Gossip協議也有不完美的地方，例如，拜占庭問題（Byzantine）。即，若是有一個惡意傳播消息的節點，Gossip協議的分佈式系統就會出問題。

注：Redis集羣節點通訊消息類型

全部的Redis節點經過PING-PONG機制彼此互聯，內部使用二進制協議優化傳輸速度和帶寬。

這個ping爲啥能提升傳輸速度和帶寬？ 感受不大清楚，小吒哥。那這裏和OSI網絡層級模式有關係了

在OSI網絡層級模型下，ping協議隸屬網絡層，因此它會減小網絡層級傳輸的開銷，而二進制是用最小單位0,1表示的位。

帶寬是固定的，若是你發送的數據包都很小，那傳輸就很快，並不會出現數據包很大還要拆包等複雜工做。
至關於別人出差1斤多MacPro。你出差帶5斤的戰神電腦。

Redis的瓶頸是什麼呢? 吒吒輝給安排

Redis自己就是內存數據庫，讀寫I/O是它的強項，瓶頸就在單線程I/O上與內存的容量上。 目前已經有多線程了，

例如：Redis6具有網絡傳輸的多線程模式，keydb直接就是多線程。
啥？ 還沒了解多Redis6多線程模式，後面單獨搞篇來聊聊

集羣節點故障如何發現？

節點故障是經過集羣中超過半數的節點檢測失效時纔會生效。客戶端與Redis節點直連，客戶端不須要鏈接集羣全部節點，鏈接集羣中任何一個可用節點便可。

Redis Cluster把全部的物理節點映射到slot上，cluster負責維護node、slot和value的映射關係。當節點發生故障時，選舉過程是集羣中全部master參與的，若是半數以上master節點與當前master節點間的通訊超時，則認爲當前master節點掛掉。

這爲什麼不沒得Slave節點參與呢？

集羣模式下，請求在集羣模式下會自動作到讀寫分離，即讀從寫主。但如今是選擇主節點。只能由主節點來進行身份參與。

畢竟集羣模式下，主節點有多個，每一個從節點只對應一個主節點，那這樣，你別個家的從節點可以參與選舉整個集羣模式下的主節點嗎？

就好像小姐姐有了對象，那就是名花有主，你還能在有主的狀況下，去選一個？ 當心遭到社會的毒打

若是集羣中超過半數以上master節點掛掉，不管是否有slave集羣，Redis的整個集羣將處於不可用狀態。

當集羣不可用時，全部對集羣的操做都不可用，都將收到錯誤信息:

［（error）CLUSTERDOWN The cluster is down］。

支持Redis的客戶端編程語言衆多，能夠知足絕大多數的應用，如圖所示。

3.2.多級緩存實例

一個使用了Redis集羣和其餘多種緩存技術的應用系統架構如圖所示

負載均衡

首先，用戶的請求被負載均衡服務分發到Nginx上，此處經常使用的負載均衡算法是輪詢或者一致性哈希，輪詢可使服務器的請求更加均衡，而一致性哈希能夠提高Nginx應用的緩存命中率。

什麼是一致性hash算法？

hash算法計算出的結果值自己就是惟一的，這樣就可讓每一個用戶的請求都落到同一臺服務器。
默認狀況下，用戶在那臺在服務器登陸，就生成會話session文件到該服務器，但若是下次請求從新分發給其餘服務器就又須要從新登陸。

而有了一致性hash算法就能夠治癒它，它把請求都專心交給同一臺服務器，鐵打的專注，從而避免上述問題。 固然這裏的一致性hash原理就沒給你們講了。後面安排

nginx本地緩存

請求進入到Nginx應用服務器，首先讀取本地緩存，實現本地緩存的方式能夠是Lua Shared Dict，或者面向磁盤或內存的 Nginx Proxy Cache，以及本地的Redis實現等，若是本地緩存命中則直接返回。

這本地緩存怎麼感受那麼特別呢？ 好像你家附近的小姐姐，離得這麼近，惋惜吃不着。呸呸呸，跑題啦

• Lua Shard Dict是指在nginx上，經過lua開闢一塊內存空間來存儲緩存數據。至關於用的是nginx的進程資源
• nginx Cache指nginx獲取上游服務的數據緩存到本地。
• 本地Redis指nginx和Redis部署在同一臺服務上，由nginx直接操做Redis

啥！ nginx還可直接操做Redis呀，聽我細細到來

這些方式各有千秋，Lua Shard Dict 是經過Lua腳本控制緩存數據的大小並能夠靈活的經過邏輯處理來修改相關緩存數據。

而Nginx Proxy Cache開發相對簡單，就是獲取上游數據到本地緩存處理。 而本地Redis則須要經過lua腳本編寫邏輯來設置，雖然操做繁瑣了，但解決了本地內存侷限的問題。
因此nginx操做Redis是須要藉助於 Lua 噠

nginx本地緩存有什麼優勢？

Nginx應用服務器使用本地緩存能夠提高總體的吞吐量，下降後端的壓力，尤爲應對熱點數據的反覆讀取問題很是有效。

本地緩存未命中時如何解決？

若是Nginx應用服務器的本地緩存沒有命中，就會進一步讀取相應的分佈式緩存——Redis分佈式緩存的集羣，能夠考慮使用主從架構來提高性能和吞吐量，若是分佈式緩存命中則直接返回相應數據，並回寫到Nginx應用服務器的本地緩存中。

若是Redis分佈式緩存也沒有命中，則會回源到Tomcat集羣，在回源到Tomcat集羣時也可使用輪詢和一致性哈希做爲負載均衡算法。

那我是PHP技術棧咋辦？都不會用到java的Tomcat呀
nginx經常使用於反向代理層。而這裏的Tomcat更可能是屬於應用服務器，若是換成PHP，那就由php-fpm或者swoole服務來接受請求。即無論什麼語言，都應該找對應語言接受請求分發的東西。

固然，若是Redis分佈式緩存沒有命中的話，Nginx應用服務器還能夠再嘗試一次讀主Redis集羣操做，目的是防止當從Redis集羣有問題時可能發生的流量衝擊。

這樣的設計方案我在下表示看不懂

若是你網站流量比較大，若是一次在Redis分佈式緩存中未讀取到的話，直接透過到數據庫，那流量可能會把數據庫沖垮。這裏的一次讀主也是考慮到Redis集羣中的主從延遲問題，爲的就是防止緩存擊穿。

在Tomcat | PHP-FPM集羣應用中，首先讀取本地平臺級緩存，若是平臺級緩存命中則直接返回數據，並會同步寫到主Redis集羣，在由主從同步到從Redis集羣。

此處可能存在多個Tomcat實例同時寫主Redis集羣的狀況，可能會形成數據錯亂，須要注意緩存的更新機制和原子化操做。

如何保證原子化操做執行呢？

當多個實例要同時要寫Redis緩存時，爲了保持原子化，起碼得在涉及這塊業務多個的 Key 上採用lua腳本進行封裝，而後再經過分佈式鎖或去重相同請求併入到一個隊列來獲取，讓獲取到鎖或從隊列pop的請求去讀取Redis集羣中的數據。

若是全部緩存都沒有命中，系統就只能查詢數據庫或其餘相關服務獲取相關數據並返回，固然，咱們已經知道數據庫也是有緩存的。 是否是安排得明明白白。

這就是多級緩存的使用，才能保障系統具有優良的性能。

何時，小姐姐也能明白俺的良苦心。。。。 默默的獨自流下了淚水

3.3.緩存算法

緩存通常都會採用內存來作存儲介質，使用索引成本相對來講仍是比較高的。因此在使用緩存時，須要瞭解緩存技術中的幾個術語。

緩存淘汰算法

替代策略的具體實現就是緩存淘汰算法。

使用頻率：

1. Least-Recently-Used（LRU） 替換掉最近被請求最少的對象。

在CPU緩存淘汰和虛擬內存系統中效果很好。然而在直接應用與代理緩存中效果欠佳，由於Web訪問的時間局部性經常變化很大。
瀏覽器就通常使用了LRU做爲緩存算法。新的對象會被放在緩存的頂部，當緩存達到了容量極限，底部的對象被去除，方法就是把最新被訪問的緩存對象放到緩存池的頂部。

1. Least-Frequently-Used（LFU） 替換掉訪問次數最少的緩存，這一策略意圖是保留最經常使用的、最流行的對象，替換掉不多使用的那些數據。

然而，有的文檔可能有很高的使用頻率，但以後不再會用到。傳統的LFU策略沒有提供任何移除這類文件的機制，所以會致使「緩存污染」，即一個先前流行的緩存對象會在緩存中駐留很長時間，這樣，就阻礙了新進來可能會流行的對象對它的替代。

1. Pitkow/Recker 替換最近最少使用的對象

除非全部對象都是今天訪問過的。若是是這樣，則替換掉最大的對象。這一策略試圖符合每日訪問Web網頁的特定模式。這一策略也被建議在天天結束時運行，以釋放被「舊的」、最近最少使用的對象佔用的空間。

1. Adaptive Replacement Cache（ARC） ARC介於LRU和LFU之間，爲了提升效果，由2個LRU組成。

第一個包含的條目是最近只被使用過一次的，而第二個LRU包含的是最近被使用過兩次的條目，所以，獲得了新的對象和經常使用的對象。ARC可以自我調節，而且是低負載的。

1. Most Recently Used（MRU） MRU與LRU是相對，移除最近最多被使用的對象。

當一次訪問過來的時候，有些事情是沒法預測的，而且在存系統中找出最少最近使用的對象是一項時間複雜度很是高的運算，這時會考慮MRU，在數據庫內存緩存中比較常見。

訪問計數

1. Least Recently Used2 (LRU2）

LRU的變種，把被兩次訪問過的對象放入緩存池，當緩存池滿了以後，會把有兩次最少使用的緩存對象去除。

由於須要跟蹤對象2次，訪問負載就會隨着緩存池的增長而增長。

1. Two Queues（2Q） Two Queues是LRU的另外一個變種。

把被訪問的數據放到LRU的緩存中，若是這個對象再一次被訪問，就把他轉移到第二個、更大的LRU緩存，使用了多級緩存的方式。去除緩存對象是爲了保持第一個緩存池是第二個緩存池的1/3。

當緩存的訪問負載是固定的時候，把LRU換成LRU2，就比增長緩存的容量更好。

緩存容量算法

1. SIZE 替換佔用空間最大的對象，這一策略經過淘汰一個大對象而不是多個小對象來提升命中率。不過，可能有些進入緩存的小對象永遠不會再被訪問。SIZE策略沒有提供淘汰這類對象的機制，也會致使「緩存污染」。
2. LRU-Threshold 不緩存超過某一size的對象，其餘與LRU相同。
3. Log（Size）+LRU 替換size最大的對象，當size相同時，按LRU進行替換。

緩存時間

1. Hyper-G LFU的改進版，同時考慮上次訪問時間和對象size。
2. Lowest-Latency-First 替換下載時間最少的文檔。顯然它的目標是最小化平均延遲。

緩存評估

1. Hybrid Hybrid 有一個目標是減小平均延遲。

對緩存中的每一個文檔都會計算一個保留效用，保留效用最低的對象會被替換掉。位於服務器S的文檔f的效用函數定義以下：

Cs是與服務器s的鏈接時間；
bs是服務器s的帶寬；frf表明f的使用頻率；sizef是文檔f的大小，單位字節。K1和K2是常量，Cs和bs是根據最近從服務器s獲取文檔的時間進行估計的。

1. Lowest Relative Value（LRV） LRV也是基於計算緩存中文檔的保留效用，而後替換保留效用最低的文檔。

隨機與隊列算法

1. First in First out（FIFO）

FIFO經過一個隊列去跟蹤全部的緩存對象，最近最經常使用的緩存對象放在後面，而更早的緩存對象放在前面，當緩存容量滿時，排在前面的緩存對象會被踢走，而後把新的緩存對象加進去。

1. Random Cache 隨機緩存就是隨意的替換緩存數據，比FIFO機制好，在某些狀況下，甚至比LRU好，可是一般LRU都會比隨機緩存更好些。

還有不少的緩存算法，例如Second Chance、Clock、Simple time-based、Extended time-based expiration、Sliding time-based expiration……各類緩存算法沒有優劣之分，不一樣的實際應用場景，會用到不一樣的緩存算法。在實現緩存算法的時候，一般會考慮使用頻率、獲取成本、緩存容量和時間等因素。

04.使用公有云的緩存服務

國內的共有云服務提供商如阿里雲、青雲、百度雲等都推出了基於Redis的雲存儲服務，這些服務的有以下特色：

• 動態擴容：

用戶能夠經過控制面板升級所需Redis的存儲空間，擴容過程當中服務不須要中斷或中止，整個擴容過程對用戶是透明且無感知的，而自主使用集羣解決Redis平滑擴容是個很煩瑣的任務，如今須要用你的小手按幾下鼠標就能搞定，大大減小了運維的負擔。

• 數據多備：

數據保存在一主一備兩臺機器中，其中一臺機器宕機了，數據還在另一臺機器上有備份。

• 自動容災：

主機宕機後系統能自動檢測並切換到備機上，實現了服務的高可用性。

• 成本較低：

在不少狀況下，爲使Redis的性能更好，須要購買一臺專門的服務器用於Redis的存儲服務，但這樣會致使某些資源的浪費，購買Redis雲存儲服務就能很好地解決這樣的問題。

有了Redis雲存儲服務，能使後臺開發人員從煩瑣的運維中解放出來。應用後臺服務中，若是自主搭建一個高可用、高性能的Redis集羣服務，是須要投入至關的運維成本和精力。

若是使用雲服務，就不必投入這些成本和精力，可讓後臺應用的開發人員更專一於業務。

我是吒吒輝，就愛分析進階相關知識，下期在見。若是以爲文章對你有幫助，歡迎分享+關注額。 同時這邊我也整理了後端系統提高的電子書和技術問題的知識卡片，也一併分享給你們，後面將持續更新，大家的關注將是我繼續寫做下去的最大動力。 須要的小夥伴可微信搜索【蓮花童子哪吒】