為啥平臺緩存還不能滿足系統(tǒng)性能要求呢？它不是還可以減少應(yīng)用緩存的網(wǎng)絡(luò)開銷嗎 那你得看這幾點：

3.1面向Redis的緩存應(yīng)用

Redis是一款開源的、基于BSD許可的高級鍵值對緩存和存儲系統(tǒng)，例如：新浪微博有著幾乎世界上最大的Redis集群。

為何新浪微博是世界上最大的Redis集群呢？

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

在這種數(shù)據(jù)關(guān)系復(fù)雜、易變化的場景上面用到它會顯得很簡單。比如：

「用戶關(guān)注與取消」：用hash就可以很方便的維護(hù)用戶列表，你可以直接找到key,然后更改value里面的關(guān)注用戶即可。

如果你像  memcache ，那只能先序列化好用戶關(guān)注列表存儲，更改在反序列化。然后再緩存起來，像大V有幾百萬、上千萬的用戶，一旦關(guān)注/取消。當(dāng)前任務(wù)的操作就會有延遲。

Reddis主要功能特點

• 主從同步
  Redis支持主從同步，數(shù)據(jù)可以從主服務(wù)器向任意數(shù)量的從服務(wù)器同步， 「從服務(wù)器可做為」關(guān)聯(lián)其他從服務(wù)器的主服務(wù)器。這使得Redis可執(zhí)行單層樹狀復(fù)制。

• 發(fā)布/訂閱
  由于實現(xiàn)了 「發(fā)布/訂閱機(jī)制」，使得從服務(wù)器在任何地方同步樹的時候，可訂閱一個頻道并接收主服務(wù)器完整的消息發(fā)布記錄。同步對讀取操作的可擴(kuò)展性和數(shù)據(jù)冗余很有幫助。

• 集群
  Redis 3.0版本加入cluster功能， 「解決了Redis單點無法橫向擴(kuò)展的問題」。Redis集群采用無中心節(jié)點方式實現(xiàn)，無需proxy代理，客戶端直接與Redis集群的每個節(jié)點連接，根據(jù)同樣的哈希算法計算出key對應(yīng)的slot，然后直接在slot對應(yīng)的Redis上執(zhí)行命令。

從Redis視角來看，響應(yīng)時間是最苛刻的條件，增加一層帶來的開銷是不能接受的。因此，Redis實現(xiàn)了客戶端對節(jié)點的直接訪問，為了去中心化，節(jié)點之間通過Gossip協(xié)議交換相互的狀態(tài)，以及探測新加入的節(jié)點信息。Redis集群支持動態(tài)加入節(jié)點，動態(tài)遷移slot，以及自動故障轉(zhuǎn)移。

Redis集群的架構(gòu)示意如圖所示。

那什么是 Gossip 協(xié)議呢？感覺好高大上，各種協(xié)議頻繁出現(xiàn)

Gossip 協(xié)議是一個多播協(xié)議，基本思想是：
一個節(jié)點想要分享一些信息給網(wǎng)絡(luò)中的其他的一些節(jié)點。于是，它周期性的隨機(jī)選擇一些節(jié)點，并把信息傳遞給這些節(jié)點。這些收到信息的節(jié)點接下來會做同樣的事情，即把這些信息傳遞給其他一些隨機(jī)選擇的節(jié)點。直至全部的節(jié)點。

即，Redis集群中添加、剔除、選舉主節(jié)點，都是基于這樣的方式。

例如：當(dāng)加入新節(jié)點時(meet)，集群中會隨機(jī)選擇一個節(jié)點來邀請「新節(jié)點」，此時只有邀請節(jié)點和被邀請節(jié)點知道這件事，其余節(jié)點要等待 ping 消息一層一層擴(kuò)散。除了 Fail 是立即全網(wǎng)通知的，其他諸如新節(jié)點、節(jié)點重上線、從節(jié)點選舉成為主節(jié)點、槽變化等，都需要等待被通知到，所以Gossip協(xié)議也是最終一致性的協(xié)議。

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

然而，Gossip協(xié)議也有不完美的地方，例如，拜占庭問題（Byzantine）。即，如果有一個惡意傳播消息的節(jié)點，Gossip協(xié)議的分布式系統(tǒng)就會出問題。

注：Redis集群節(jié)點通信消息類型

所有的Redis節(jié)點通過PING-PONG機(jī)制彼此互聯(lián)，內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬。

這個ping為啥能提高傳輸速度和帶寬？感覺不大清楚，小吒哥。那這里和OSI網(wǎng)絡(luò)層級模式有關(guān)系了

在OSI網(wǎng)絡(luò)層級模型下，ping協(xié)議隸屬網(wǎng)絡(luò)層，所以它會減少網(wǎng)絡(luò)層級傳輸?shù)拈_銷，而二進(jìn)制是用最小單位0,1表示的位。

帶寬是固定的，如果你發(fā)送的數(shù)據(jù)包都很小，那傳輸就很快，并不會出現(xiàn)數(shù)據(jù)包很大還要拆包等復(fù)雜工作。
相當(dāng)于別人出差1斤多MacPro。你出差帶5斤的戰(zhàn)神電腦。

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

Redis本身就是內(nèi)存數(shù)據(jù)庫，讀寫I/O是它的強(qiáng)項，瓶頸就在單線程I/O上與內(nèi)存的容量上。目前已經(jīng)有多線程了，

例如：Redis6具備網(wǎng)絡(luò)傳輸?shù)亩嗑€程模式，keydb直接就是多線程。
啥？還沒了解多Redis6多線程模式，后面單獨搞篇來聊聊

集群節(jié)點故障如何發(fā)現(xiàn)？

「節(jié)點故障」是通過「集群中超過半數(shù)的節(jié)點檢測失效時才會生效」?？蛻舳伺cRedis節(jié)點直連，客戶端不需要連接集群所有節(jié)點，連接集群中任何一個可用節(jié)點即可。

Redis Cluster把所有的物理節(jié)點映射到slot上，cluster負(fù)責(zé)維護(hù)node、slot和value的映射關(guān)系。當(dāng)節(jié)點發(fā)生故障時，選舉過程是集群中所有master參與的，如果半數(shù)以上master節(jié)點與當(dāng)前master節(jié)點間的通信超時，則認(rèn)為當(dāng)前master節(jié)點掛掉。

這為何不沒得Slave節(jié)點參與呢？

集群模式下，請求在集群模式下會自動做到讀寫分離，即讀從寫主。但現(xiàn)在是選擇主節(jié)點。只能由主節(jié)點來進(jìn)行身份參與。

畢竟集群模式下，主節(jié)點有多個，每個從節(jié)點只對應(yīng)一個主節(jié)點，那這樣，你別個家的從節(jié)點能夠參與選舉整個集群模式下的主節(jié)點嗎？

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

如果集群中超過半數(shù)以上master節(jié)點掛掉，無論是否有slave集群，Redis的整個集群將處于不可用狀態(tài)。

當(dāng)集群不可用時，所有對集群的操作都不可用，都將收到錯誤信息:

［（error）CLUSTERDOWN The cluster is down］。

支持Redis的客戶端編程語言眾多，可以滿足絕大多數(shù)的應(yīng)用，如圖所示。

3.2.多級緩存實例

一個使用了Redis集群和其他多種緩存技術(shù)的應(yīng)用系統(tǒng)架構(gòu)如圖所示

負(fù)載均衡

首先，用戶的請求被負(fù)載均衡服務(wù)分發(fā)到Nginx上，此處常用的負(fù)載均衡算法是輪詢或者一致性哈希，輪詢可以使服務(wù)器的請求更加均衡，而一致性哈?？梢蕴嵘齆ginx應(yīng)用的緩存命中率。

什么是一致性hash算法？

hash算法計算出的結(jié)果值本身就是唯一的，這樣就可以讓每個用戶的請求都落到同一臺服務(wù)器。
默認(rèn)情況下，用戶在那臺在服務(wù)器登錄，就生成會話session文件到該服務(wù)器，但如果下次請求重新分發(fā)給其他服務(wù)器就又需要重新登錄。

而有了一致性hash算法就可以治愈它，它把請求都專心交給同一臺服務(wù)器，鐵打的專一，從而避免上述問題。 當(dāng)然這里的一致性hash原理就沒給大家講了。后面安排

nginx本地緩存

請求進(jìn)入到Nginx應(yīng)用服務(wù)器，首先讀取本地緩存，實現(xiàn)本地緩存的方式可以是Lua Shared Dict，或者面向磁盤或內(nèi)存的 Nginx Proxy Cache，以及本地的Redis實現(xiàn)等，如果本地緩存命中則直接返回。

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

• Lua Shard Dict是指在nginx上，通過lua開辟一塊內(nèi)存空間來存儲緩存數(shù)據(jù)。相當(dāng)于用的是nginx的進(jìn)程資源
• nginx Cache指nginx獲取上游服務(wù)的數(shù)據(jù)緩存到本地。
• 本地Redis指nginx和Redis部署在同一臺服務(wù)上，由nginx直接操作Redis

啥！nginx還可直接操作Redis呀，聽我細(xì)細(xì)到來

這些方式各有千秋，Lua Shard Dict 是通過Lua腳本控制緩存數(shù)據(jù)的大小并可以靈活的通過邏輯處理來修改相關(guān)緩存數(shù)據(jù)。

而Nginx Proxy Cache開發(fā)相對簡單，就是獲取上游數(shù)據(jù)到本地緩存處理。而「本地Redis則需要通過lua腳本編寫邏輯來設(shè)置」，雖然操作繁瑣了，但解決了本地內(nèi)存局限的問題。
所以nginx操作Redis是需要借助于 Lua 噠

nginx本地緩存有什么優(yōu)點？

Nginx應(yīng)用服務(wù)器使用本地緩存可以提升整體的吞吐量，降低后端的壓力，尤其應(yīng)對熱點數(shù)據(jù)的反復(fù)讀取問題非常有效。

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

如果Nginx應(yīng)用服務(wù)器的本地緩存沒有命中，就會進(jìn)一步讀取相應(yīng)的分布式緩存——Redis分布式緩存的集群，可以考慮使用主從架構(gòu)來提升性能和吞吐量，如果分布式緩存命中則直接返回相應(yīng)數(shù)據(jù)，并回寫到Nginx應(yīng)用服務(wù)器的本地緩存中。

如果Redis分布式緩存也沒有命中，則會回源到Tomcat集群，在回源到Tomcat集群時也可以使用輪詢和一致性哈希作為負(fù)載均衡算法。

那我是PHP技術(shù)棧咋辦？都不會用到j(luò)ava的Tomcat呀
nginx常用于反向代理層。而這里的Tomcat更多是屬于應(yīng)用服務(wù)器，如果換成PHP，那就由php-fpm或者swoole服務(wù)來接受請求。即不管什么語言，都應(yīng)該找對應(yīng)語言接受請求分發(fā)的東西。

當(dāng)然，如果Redis分布式緩存沒有命中的話，Nginx應(yīng)用服務(wù)器還可以再嘗試一次讀主Redis集群操作，目的是防止當(dāng)從Redis集群有問題時可能發(fā)生的流量沖擊。

這樣的設(shè)計方案我在下表示看不懂

如果你網(wǎng)站流量比較大，如果一次在Redis分布式緩存中未讀取到的話，直接透過到數(shù)據(jù)庫，那流量可能會把數(shù)據(jù)庫沖垮。這里的一次讀主也是考慮到Redis集群中的主從延遲問題，為的就是防止緩存擊穿。

在Tomcat | PHP-FPM集群應(yīng)用中，首先讀取本地平臺級緩存，如果平臺級緩存命中則直接返回數(shù)據(jù)，并會同步寫到主Redis集群，在由主從同步到從Redis集群。

此處可能存在多個Tomcat實例同時寫主Redis集群的情況，可能會造成數(shù)據(jù)錯亂，需要注意緩存的更新機(jī)制和原子化操作。

如何保證原子化操作執(zhí)行呢？

當(dāng)多個實例要同時要寫Redis緩存時，為了保持原子化，起碼得在涉及這塊業(yè)務(wù)多個的 Key 上采用lua腳本進(jìn)行封裝，然后再通過分布式鎖或去重相同請求并入到一個隊列來獲取，讓獲取到鎖或從隊列pop的請求去讀取Redis集群中的數(shù)據(jù)。

如果所有緩存都沒有命中，系統(tǒng)就只能查詢數(shù)據(jù)庫或其他相關(guān)服務(wù)獲取相關(guān)數(shù)據(jù)并返回，當(dāng)然，我們已經(jīng)知道數(shù)據(jù)庫也是有緩存的。是不是安排得明明白白。

這就是多級緩存的使用，才能保障系統(tǒng)具備優(yōu)良的性能。

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

3.3.緩存算法

緩存一般都會采用內(nèi)存來做存儲介質(zhì)，使用索引成本相對來說還是比較高的。所以在使用緩存時，需要了解緩存技術(shù)中的幾個術(shù)語。

緩存淘汰算法

替代策略的具體實現(xiàn)就是緩存淘汰算法。

使用頻率：

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

在CPU緩存淘汰和虛擬內(nèi)存系統(tǒng)中效果很好。然而在直接應(yīng)用與代理緩存中效果欠佳，因為Web訪問的時間局部性常常變化很大。
瀏覽器就一般使用了LRU作為緩存算法。新的對象會被放在緩存的頂部，當(dāng)緩存達(dá)到了容量極限，底部的對象被去除，方法就是把最新被訪問的緩存對象放到緩存池的頂部。

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

然而，有的文檔可能有很高的使用頻率，但之后再也不會用到。傳統(tǒng)的LFU策略沒有提供任何移除這類文件的機(jī)制，因此會導(dǎo)致“緩存污染”，即一個先前流行的緩存對象會在緩存中駐留很長時間，這樣，就阻礙了新進(jìn)來可能會流行的對象對它的替代。

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

除非所有對象都是今天訪問過的。如果是這樣，則替換掉最大的對象。這一策略試圖符合每日訪問Web網(wǎng)頁的特定模式。這一策略也被建議在每天結(jié)束時運行，以釋放被“舊的”、最近最少使用的對象占用的空間。

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

第一個包含的條目是最近只被使用過一次的，而第二個LRU包含的是最近被使用過兩次的條目，因此，得到了新的對象和常用的對象。ARC能夠自我調(diào)節(jié)，并且是低負(fù)載的。

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

當(dāng)一次訪問過來的時候，有些事情是無法預(yù)測的，并且在存系統(tǒng)中找出最少最近使用的對象是一項時間復(fù)雜度非常高的運算，這時會考慮MRU，在數(shù)據(jù)庫內(nèi)存緩存中比較常見。

訪問計數(shù)

1. Least Recently Used2  (LRU2）

LRU的變種，把被兩次訪問過的對象放入緩存池，當(dāng)緩存池滿了之后，會把有兩次最少使用的緩存對象去除。

因為需要跟蹤對象2次，訪問負(fù)載就會隨著緩存池的增加而增加。

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

把被訪問的數(shù)據(jù)放到LRU的緩存中，如果這個對象再一次被訪問，就把他轉(zhuǎn)移到第二個、更大的LRU緩存，使用了多級緩存的方式。去除緩存對象是為了保持第一個緩存池是第二個緩存池的1/3。

當(dāng)緩存的訪問負(fù)載是固定的時候，把LRU換成LRU2，就比增加緩存的容量更好。

緩存容量算法

1. SIZE 替換占用空間最大的對象，這一策略通過淘汰一個大對象而不是多個小對象來提高命中率。不過，可能有些進(jìn)入緩存的小對象永遠(yuǎn)不會再被訪問。SIZE策略沒有提供淘汰這類對象的機(jī)制，也會導(dǎo)致“緩存污染”。

2. LRU-Threshold 不緩存超過某一size的對象，其他與LRU相同。

3. Log（Size）+LRU 替換size最大的對象，當(dāng)size相同時，按LRU進(jìn)行替換。

緩存時間

1. Hyper-G LFU的改進(jìn)版，同時考慮上次訪問時間和對象size。

2. Lowest-Latency-First 替換下載時間最少的文檔。顯然它的目標(biāo)是最小化平均延遲。

緩存評估

1. Hybrid Hybrid 有一個目標(biāo)是減少平均延遲。

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

Cs是與服務(wù)器s的連接時間；
bs是服務(wù)器s的帶寬；frf代表f的使用頻率；sizef是文檔f的大小，單位字節(jié)。K1和K2是常量，Cs和bs是根據(jù)最近從服務(wù)器s獲取文檔的時間進(jìn)行估計的。

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

隨機(jī)與隊列算法

1. First in First out（FIFO）

FIFO通過一個隊列去跟蹤所有的緩存對象，最近最常用的緩存對象放在后面，而更早的緩存對象放在前面，當(dāng)緩存容量滿時，排在前面的緩存對象會被踢走，然后把新的緩存對象加進(jìn)去。

1. Random Cache 隨機(jī)緩存就是隨意的替換緩存數(shù)據(jù)，比FIFO機(jī)制好，在某些情況下，甚至比LRU好，但是通常LRU都會比隨機(jī)緩存更好些。

還有很多的緩存算法，例如Second Chance、Clock、Simple time-based、Extended time-based expiration、Sliding time-based expiration……各種緩存算法沒有優(yōu)劣之分，不同的實際應(yīng)用場景，會用到不同的緩存算法。在實現(xiàn)緩存算法的時候，通常會考慮**使用頻率、獲取成本、緩存容量和時間等因素。 **

04.使用公有云的緩存服務(wù)

國內(nèi)的共有云服務(wù)提供商如阿里云、青云、百度云等都推出了基于Redis的云存儲服務(wù)，這些服務(wù)的有如下特點：

• 動態(tài)擴(kuò)容：

用戶可以通過控制面板升級所需Redis的存儲空間，「擴(kuò)容過程中服務(wù)不需要中斷或停止」，整個擴(kuò)容過程對用戶是透明且無感知的，而自主使用集群解決Redis平滑擴(kuò)容是個很煩瑣的任務(wù)，現(xiàn)在需要用你的小手按幾下鼠標(biāo)就能搞定，大大減少了運維的負(fù)擔(dān)。

• 數(shù)據(jù)多備：
  數(shù)據(jù)保存在一主一備兩臺機(jī)器中，其中一臺機(jī)器宕機(jī)了，數(shù)據(jù)還在另外一臺機(jī)器上有備份。
• 自動容災(zāi)：
  主機(jī)宕機(jī)后系統(tǒng)能自動檢測并切換到備機(jī)上，實現(xiàn)了服務(wù)的高可用性。
• 成本較低：
  在很多情況下，為使Redis的性能更好，需要購買一臺專門的服務(wù)器用于Redis的存儲服務(wù)，但這樣會導(dǎo)致某些資源的浪費，購買Redis云存儲服務(wù)就能很好地解決這樣的問題。

有了Redis云存儲服務(wù)，能使后臺開發(fā)人員從煩瑣的運維中解放出來。應(yīng)用后臺服務(wù)中，如果自主搭建一個高可用、高性能的Redis集群服務(wù)，是需要投入相當(dāng)?shù)倪\維成本和精力。

如果使用云服務(wù)，就沒必要投入這些成本和精力，可以讓后臺應(yīng)用的開發(fā)人員更專注于業(yè)務(wù)。