緩存在大型分布式系統中的最佳應用

轉自

本文大綱：

1. 緩存概述
2. CDN緩存
3. 反向代理緩存
4. 分布式緩存
5. 本地緩存
6. 緩存架構示例
7. 緩存常見問題

一、緩存概述

緩存是分布式系統中的重要元件，主要解決高并發，大資料場景下，熱點資料通路的性能問題。提供高性能的資料快速通路。

1、緩存的原理

• 将資料寫入/讀取速度更快的存儲（裝置）；
• 将資料緩存到離應用最近的位置；
• 将資料緩存到離使用者最近的位置。

2、緩存分類

在分布式系統中，緩存的應用非常廣泛，從部署角度有以下幾個方面的緩存應用。

• CDN緩存；
• 反向代理緩存；
• 分布式Cache；
• 本地應用緩存；

3、緩存媒介

• 常用中間件：Varnish，Ngnix，Squid，Memcache，Redis，Ehcache等；
• 緩存的内容：檔案，資料，對象；
• 緩存的媒體：CPU，記憶體（本地，分布式），磁盤（本地，分布式）

4、緩存設計

緩存設計需要解決以下幾個問題：

緩存什麼？

哪些資料需要緩存：1.熱點資料；2.靜态資源。

緩存的位置？

CDN，反向代理，分布式緩存伺服器，本機（記憶體，硬碟）

如何緩存的問題？

• 過期政策
• 固定時間：比如指定緩存的時間是30分鐘；
• 相對時間：比如最近10分鐘内沒有通路的資料；
• 同步機制
• 實時寫入；（推）
• 異步重新整理；（推拉）

二、CDN緩存

CDN主要解決将資料緩存到離使用者最近的位置，一般緩存靜态資源檔案（頁面，腳本，圖檔，視訊，檔案等）。國内網絡異常複雜，跨營運商的網絡通路會很慢。為了解決跨營運商或各地使用者通路問題，可以在重要的城市，部署CDN應用。使使用者就近擷取所需内容，降低網絡擁塞，提高使用者通路響應速度和命中率。

1、CND原理

CDN的基本原理是廣泛采用各種緩存伺服器，将這些緩存伺服器分布到使用者通路相對集中的地區或網絡中，在使用者通路網站時，利用全局負載技術将使用者的通路指向距離最近的工作正常的緩存伺服器上，由緩存伺服器直接響應使用者請求。

（1）未部署CDN應用前

網絡請求路徑：

• 請求：本機網絡（區域網路）——》營運商網絡——》應用伺服器機房
• 響應：應用伺服器機房——》營運商網絡——》本機網絡（區域網路）

在不考慮複雜網絡的情況下，從請求到響應需要經過3個節點，6個步驟完成一次使用者通路操作。

（2）部署CDN應用後

網絡路徑：

• 請求：本機網絡（區域網路）——》營運商網絡
• 響應：營運商網絡——》本機網絡（區域網路）

在不考慮複雜網絡的情況下，從請求到響應需要經過2個節點，2個步驟完成一次使用者通路操作。

與不部署CDN服務相比，減少了1個節點，4個步驟的通路。極大的提高的系統的響應速度。

2、CDN優缺點

優點（摘自百度百科）：

本地Cache加速：提升通路速度，尤其含有大量圖檔和靜态頁面站點。

鏡像服務：消除了不同營運商之間互聯的瓶頸造成的影響，實作了跨營運商的網絡加速，保證不同網絡中的使用者都能得到良好的通路品質。

遠端加速：遠端通路使用者根據DNS負載均衡技術智能自動選擇Cache伺服器，選擇最快的Cache伺服器，加快遠端通路的速度。

帶寬優化：自動生成伺服器的遠端Mirror（鏡像）cache伺服器，遠端使用者通路時從cache伺服器上讀取資料，減少遠端通路的帶寬、分擔網絡流量、減輕原站點WEB伺服器負載等功能。

叢集抗攻擊：廣泛分布的CDN節點加上節點之間的智能備援機制，可以有效地預防黑客入侵以及降低各種D.D.o.S攻擊對網站的影響，同時保證較好的服務品質。

缺點：

• 動态資源緩存，需要注意實時性；

解決：主要緩存靜态資源，動态資源建立多級緩存或準實時同步；

• 如何保證資料的一緻性和實時性需要權衡考慮；

解決：

（1）設定緩存失效時間（1個小時，最終一緻性）；

（2）資料版本号；

3、CND架構參考

摘自《雲宙視訊CDN系統》

4、CND技術實踐

目前，中小型網際網路公司，綜合成本考慮，一般租用第三方CDN服務，大型網際網路公司，采用自建或第三方結合的方式。比如淘寶剛開始使用第三方的，當流量很大後，第三方公司無法支撐其CDN流量，淘寶最後采用自建CDN的方式實作。

淘寶CDN，如下圖（來自網絡）：

三、反向代理緩存

反向代理是指在網站伺服器機房部署代理伺服器，實作負載均衡、資料緩存、安全控制等功能。

1、緩存原理

反向代理位于應用伺服器機房，處理所有對WEB伺服器的請求。如果使用者請求的頁面在代理伺服器上有緩沖的話，代理伺服器直接将緩沖内容發送給使用者。如果沒有緩沖則先向WEB伺服器送出請求，取回資料，本地緩存後再發送給使用者。通過降低向WEB伺服器的請求數，進而降低了WEB伺服器的負載。

反向代理一般緩存靜态資源，動态資源轉發到應用伺服器處理。常用的緩存應用伺服器有Varnish、Ngnix、Squid。

2、Squid示例

Squid 反向代理一般隻緩存靜态資源，動态程式預設不緩存。根據從 WEB 伺服器傳回的 HTTP 頭标記來緩沖靜态頁面。有四個最重要 HTTP 頭标記：

• Last-Modified：告訴反向代理頁面什麼時間被修改
• Expires：告訴反向代理頁面什麼時間應該從緩沖區中删除
• Cache-Control：告訴反向代理頁面是否應該被緩沖
• Pragma用來包含實作特定的指令，最常用的是 Pragma:no-cache

Squid 反向代理加速網站執行個體

• 通過DNS的輪詢技術，将用戶端的請求分發給其中一台 Squid 反向代理伺服器處理；
• 如果這台 Squid 緩存了使用者的請求資源，則将請求的資源直接傳回給使用者；
• 否則這台 Squid 将沒有緩存的請求根據配置的規則發送給鄰居 Squid 和背景的 WEB 伺服器處理；
• 這樣既減輕背景 WEB 伺服器的負載，又提高整個網站的性能和安全性。

2、代理緩存比較

常用的代理緩存有Varnish，Squid，Ngnix，簡單比較如下：

（1）varnish和squid是專業的cache服務，nginx需要第三方子產品支援；

（2） Varnish采用記憶體型緩存，避免了頻繁在記憶體、磁盤中交換檔案，性能比Squid高；

（3）Varnish由于是記憶體cache，是以對小檔案如css,js,小圖檔啥的支援很棒，後端的持久化緩存可以采用的是Squid或ATS；

（4）Squid功能全而大，适合于各種靜态的檔案緩存，一般會在前端挂一個HAProxy或nginx做負載均衡跑多個執行個體；

（5）Nginx采用第三方子產品ncache做的緩沖，性能基本達到varnish，一般作為反向代理使用，可以實作簡單的緩存。

四、分布式緩存

CDN，反向代理緩存，主要解決靜态檔案，或使用者請求資源的緩存，資料源一般為靜态檔案或動态生成的檔案（有緩存頭辨別）。

而分布式緩存，主要指緩存使用者經常通路資料的緩存，資料源為資料庫。一般起到熱點資料通路和減輕資料庫壓力的作用。

目前分布式緩存設計，在大型網站架構中是必備的架構要素。常用的中間件有Memcache，Redis。

1、Memcache

Memcache是一個高性能，分布式記憶體對象緩存系統，通過在記憶體裡維護一個統一的巨大的hash表，它能夠用來存儲各種格式的資料，包括圖像、視訊、檔案以及資料庫檢索的結果等。簡單的說就是将資料調用到記憶體中，然後從記憶體中讀取，進而大大提高讀取速度。

Memcache特性：

（1）使用實體記憶體作為緩存區，可獨立運作在伺服器上。每個程序最大2G，如果想緩存更多的資料，可以開辟更多的Memcache程序（不同端口）或者使用分布式Memcache進行緩存，将資料緩存到不同的實體機或者虛拟機上。

（2）使用key-value的方式來存儲資料，這是一種單索引的結構化資料組織形式，可使資料項查詢時間複雜度為O(1)。

（3）協定簡單：基于文本行的協定，直接通過telnet在memcached伺服器上可進行存取資料操作，簡單，友善多種緩存參考此協定。

（4）基于Libevent高性能通信：Libevent是一套利用C開發的程式庫，它将BSD系統的kqueue，Linux系統的epoll等事件處理功能封裝成一個接口，與傳統的select相比，提高了性能。

（5）内置的記憶體管理方式：所有資料都儲存在記憶體中，存取資料比硬碟快，當記憶體滿後，通過LRU算法自動删除不使用的緩存，但沒有考慮資料的容災問題，重新開機服務，所有資料會丢失。

（6）分布式：各個memcached伺服器之間互不通信，各自獨立存取資料，不共享任何資訊。伺服器并不具有分布式功能，分布式部署取決于Memcache用戶端。

（7）緩存政策：memcached的緩存政策是LRU（最近最少使用）到期失效政策。在memcached記憶體儲資料項時，可以指定它在緩存的失效時間，預設為永久。當memcached伺服器用完配置設定的内時，失效的資料被首先替換，然後也是最近未使用的資料。在LRU中，memcached使用的是一種Lazy Expiration政策，自己不會監控存入的key/vlue對是否過期，而是在擷取key值時檢視記錄的時間戳，檢查key/value對空間是否過期，這樣可減輕伺服器的負載。

Memcache工作原理：

Memcache的工作流程如下：

（1）先檢查用戶端的請求資料是否在memcached中，如有，直接把請求資料傳回，不再對資料庫進行任何操作。

（2） 如果請求的資料不在memcached中，就去查資料庫，把從資料庫中擷取的資料傳回給用戶端，同時把資料緩存一份到memcached中（memcached用戶端不負責，需要程式實作）。

（3）  每次更新資料庫的同時更新memcached中的資料，保證一緻性。

（4） 當配置設定給memcached記憶體空間用完之後，會使用LRU（Least Recently Used，最近最少使用）政策加上到期失效政策，失效資料首先被替換，然後再替換掉最近未使用的資料。

Memcache叢集

memcached 雖然稱為“分布式 ” 緩存伺服器，但伺服器端并沒有 “ 分布式 ” 功能。每個伺服器都是完全獨立和隔離的服務。 memcached 的分布式，是由用戶端程式實作的。

當向memcached叢集存入/取出key value時，memcached用戶端程式根據一定的算法計算存入哪台伺服器，然後再把key value值存到此伺服器中。

存取資料分二步走，第一步，選擇伺服器，第二步存取資料。

分布式算法(Consistent Hashing)：

選擇伺服器算法有兩種，一種是根據餘數來計算分布，另一種是根據雜湊演算法來計算分布。

• 餘數算法：

先求得鍵的整數散列值，再除以伺服器台數，根據餘數确定存取伺服器。

優點：計算簡單，高效。

缺點：在memcached伺服器增加或減少時，幾乎所有的緩存都會失效。

• 雜湊演算法：（一緻性Hash）

先算出memcached伺服器的散列值，并将其分布到0到2的32次方的圓上，然後用同樣的方法算出存儲資料的鍵的散列值并映射至圓上，最後從資料映射到的位置開始順時針查找，将資料儲存到查找到的第一個伺服器上，如果超過2的32次方，依然找不到伺服器，就将資料儲存到第一台memcached伺服器上。

如果添加了一台Memcached伺服器，隻在圓上增加伺服器的逆時針方向的第一台伺服器上的鍵會受到影響。

一緻性Hash算法：解決了餘數算法增加節點命中大幅額度降低的問題，理論上，插入一個實體節點，平均會影響到：虛拟節點數 /2 的節點資料的命中。

2、Redis

Redis 是一個開源（BSD許可）的，基于記憶體的，多資料結構存儲系統。可以用作資料庫、緩存和消息中間件。 支援多種類型的資料結構，如 字元串（strings）， 散列（hashes）， 清單（lists）， 集合（sets）， 有序集合（sorted sets） 與範圍查詢， bitmaps， hyperloglogs 和 地理空間（geospatial） 索引半徑查詢。

内置了 複制（replication），LUA腳本（Lua scripting）， LRU驅動事件（LRU eviction），事務（transactions） 和不同級别的 磁盤持久化（persistence）， 并通過 Redis哨兵（Sentinel）和自動分區（Cluster）提供高可用性（high availability）。

Redis常用資料類型

• String

常用指令：set，get，decr，incr，mget。

應用場景：String是最常用的一種資料類型，與Memcache的key value存儲方式類似。

實作方式：String在Redis内部存儲預設就是一個字元串，被redisObject所引用，當遇到incr，decr等操作時會轉成數值型進行計算，此時redisObject的encoding字段為int。

• Hash

常用指令：hget，hset，hgetall 。

應用場景：以存儲一個使用者資訊對象資料，為例：

實作方式：Redis Hash對應的Value，内部實際就是一個HashMap，實際這裡會有2種不同實作。

（1）Hash的成員比較少時Redis為了節省記憶體會采用類似一維數 組的方式來緊湊存儲，而不會采用真正的HashMap結構，對應的value redisObject的encoding為zipmap。

（2）當成員數量增大時會自動轉成真正的HashMap，此時encoding為ht。

List

常用指令：lpush,rpush,lpop,rpop,lrange。

應用場景：Redis list的應用場景非常多，也是Redis最重要的資料結構之一，比如twitter的關注清單，粉絲清單等都可以用Redis的list結構來實作。

實作方式：Redis list的實作為一個雙向連結清單，可以支援反向查找和周遊，友善操作。不過帶來了部分額外的記憶體開銷，Redis内部的很多實作，包括發送緩沖隊列等也都是用的這個資料結構。

Set

常用指令：sadd,spop,smembers,sunion。

應用場景：Redis set對外提供的功能與list類似是一個清單的功能，特殊之處在于set是可以自動排重的，當你需要存儲一個清單資料，又不希望出現重複資料時，set 是一個很好的選擇，并且set提供了判斷某個成員是否在一個set集合内的重要接口，這個也是list所不能提供的。

實作方式：set的内部實作是一個value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合内的原因。

Sorted set

常用指令：zadd、zrange、zrem、zcard。

使用場景：Redis sorted set的使用場景與set類似，差別是set不是自動有序的，而sorted set可以通過使用者額外提供一個優先級(score)的參數來為成員排序，并且是插入有序的，即自動排序。當你需要一個有序的并且不重複的集合清單，可以選擇sorted set資料結構，比如twitter 的public timeline可以以發表時間作為score來存儲，這樣擷取時就是自動按時間排好序的。

實作方式：Redis sorted set的内部使用HashMap和跳躍表(SkipList)來保證資料的存儲和有序，HashMap裡放的是成員到score的映射，而跳躍表裡存放的 是所有的成員，排序依據是HashMap裡存的score,使用跳躍表的結構可以獲得比較高的查找效率，并且在實作上比較簡單。

Redis叢集

（1）通過keepalived實作的高可用方案

切換流程：

1. 當Master挂了後，VIP漂移到Slave；Slave 上keepalived 通知redis 執行：slaveof no one ,開始提供業務；
2. 當Master起來後，VIP 位址不變，Master的keepalived 通知redis 執行slaveof slave IP host ，開始作為從同步資料；
3. 依次類推。

主從同時Down機情況：

• 非計劃性，不做考慮，一般也不會存在這種問題
• 計劃性重新開機，重新開機之前通過運維手段SAVE DUMP 主庫資料；需要注意順序：

1. 關閉其中一台機器上所有redis，是得master全部切到另外一台機器（多執行個體部署，單機上既有主又有從的情況）；并關閉機器
2. 依次dump主上redis服務
3. 關閉主
4. 啟動主，并等待資料load完畢
5. 啟動從
6. 删除DUMP 檔案（避免重新開機加載慢）

（2）使用Twemproxy 實作叢集方案

由twitter開源的c版本proxy，同時支援memcached和redis，目前最新版本為：0.2.4，持續開發中;https://github.com/twitter/twemproxy .twitter用它主要減少前端與緩存服務間網絡連接配接數。

特點：快、輕量級、減少後端Cache Server連接配接數、易配置、支援ketama、modula、random、常用hash分片算法。

這裡使用keepalived實作高可用主備方案，解決proxy單點問題。

優點：

1. 對于用戶端而言，redis叢集是透明的，用戶端簡單，遍于動态擴容；
2. Proxy為單點、處理一緻性hash時，叢集節點可用性檢測不存在腦裂問題；
3. 高性能，CPU密集型，而redis節點叢集多CPU資源備援，可部署在redis節點叢集上，不需要額外裝置

3、Memcache與Redis的比較

（1）資料結構：Memcache隻支援key value存儲方式，Redis支援更多的資料類型，比如Key value、hash、list、set、zset；

（2）多線程：Memcache支援多線程，Redis支援單線程；CPU利用方面Memcache優于Redis；

（3）持久化：Memcache不支援持久化，Redis支援持久化；

（4）記憶體使用率：Memcache高，Redis低（采用壓縮的情況下比Memcache高）；

（5）過期政策：Memcache過期後，不删除緩存，會導緻下次取資料資料的問題，Redis有專門線程，清除緩存資料；

五、本地緩存

本地緩存是指應用内部的緩存，标準的分布式系統，一般有多級緩存構成。本地緩存是離應用最近的緩存，一般可以将資料緩存到硬碟或記憶體。

1、硬碟緩存

将資料緩存到硬碟到，讀取時從硬碟讀取。原理是直接讀取本機檔案，減少了網絡傳輸消耗，比通過網絡讀取資料庫速度更快。可以應用在對速度要求不是很高，但需要大量緩存存儲的場景。

2、記憶體緩存

直接将資料存儲到本機記憶體中，通過程式直接維護緩存對象，是通路速度最快的方式。

六、緩存架構示例

職責劃分：

CDN：存放HTML、CSS、JS等靜态資源；

反向代理：動靜分離，隻緩存使用者請求的靜态資源；

分布式緩存：緩存資料庫中的熱點資料；

本地緩存：緩存應用字典等常用資料。

請求過程：

（1）浏覽器向用戶端發起請求，如果CDN有緩存則直接傳回；

（2）如果CDN無緩存，則通路反向代理伺服器；

（3）如果反向代理伺服器有緩存則直接傳回；

（4）如果反向代理伺服器無緩存或動态請求，則通路應用伺服器；

（5）應用伺服器通路本地緩存；如果有緩存，則傳回代理伺服器，并緩存資料；（動态請求不緩存）

（6）如果本地緩存無資料，則讀取分布式緩存；并傳回應用伺服器；應用伺服器将資料緩存到本地緩存（部分）；

（7）如果分布式緩存無資料，則應用程式讀取資料庫資料，并放入分布式緩存。

七、緩存常見問題

1、資料一緻性

緩存是在資料持久化之前的一個節點，主要是将熱點資料放到離使用者最近或通路速度更快的媒體中，加快資料的通路，減小響應時間。

因為緩存屬于持久化資料的一個副本，是以不可避免的會出現資料不一緻問題。導緻髒讀或讀不到資料的情況。資料不一緻，一般是因為網絡不穩定或節點故障導緻。根據資料的操作順序，主要有以下幾種情況。

場景介紹

（1）先寫緩存，再寫資料庫

如下圖：

假如緩存寫成功，但寫資料庫失敗或響應延遲，則下次讀取（并發讀）緩存時，就出現髒讀。

（2）先寫資料庫，再寫緩存

如下圖：

假如寫資料庫成功，但寫緩存失敗，則下次讀取（并發讀）緩存時，則讀不到資料。

（3）緩存異步重新整理

指資料庫操作和寫緩存不在一個操作步驟中，比如在分布式場景下，無法做到同時寫緩存或需要異步重新整理（補救措施）時候。

此種情況，主要考慮資料寫入和緩存重新整理的時效性。比如多久内重新整理緩存，不影響使用者對資料的通路。

解決方法

第一個場景：這個寫緩存的方式，本身就是錯誤的，需要改為先寫持久化媒體，再寫緩存的方式。

第二個場景：

（1）根據寫入緩存的響應來進行判斷，如果緩存寫入失敗，則復原資料庫操作；此種方法增加了程式的複雜度，不建議采用；

（2）緩存使用時，假如讀緩存失敗，先讀資料庫，再回寫緩存的方式實作。

第三個場景：

（1）首先确定，哪些資料适合此類場景；

（2）根據經驗值确定合理的資料不一緻時間，使用者資料重新整理的時間間隔。

其他方法

（1）逾時：設定合理的逾時時間；

（2）重新整理：定時重新整理一定範圍内（根據時間，版本号）的資料；

以上是簡化資料讀寫場景，實際中會分為：

（1）緩存與資料庫之間的一緻性；

（2）多級緩存之前的一緻性；

（3）緩存副本之前的一緻性。

2、緩存高可用

業界有兩種理論，第一套緩存就是緩存，臨時存儲資料的，不需要高可用。第二種緩存逐漸演化為重要的存儲媒體，需要做高可用。

本人的看法是，緩存是否高可用，需要根據實際的場景而定。臨界點是是否對後端的資料庫造成影響。

具體的決策依據需要根據，叢集的規模（資料，緩存），成本（伺服器，運維），系統性能（并發量，吞吐量，響應時間）等方面綜合評價。

解決方法

緩存的高可用，一般通過分布式和複制實作。分布式實作資料的海量緩存，複制實作緩存資料節點的高可用。架構圖如下：

其中，分布式采用一緻性Hash算法，複制采用異步複制。

其他方法

（1）複制雙寫：緩存節點的複制，由異步改為雙寫，隻有兩份都寫成功，才算成功。

（2）虛拟層：一緻性Hash存在，假如其中一個HASH環不可用，資料會寫入臨近的環，當HASH可用時，資料又寫入正常的HASH環，會導緻資料偏移問題。這種情況，可以考慮在HASH環前面加一個虛拟層實作。

（3）多級緩存：比如一級使用本地緩存，二級采用分布式Cahce，三級采用分布式Cache+本地持久化；

方式很多，需要根據業務場景靈活選擇。

3、緩存雪崩

雪崩是指當大量緩存失效時，導緻大量的請求通路資料庫，導緻資料庫伺服器，無法抗住請求或挂掉的情況。

解決方法：

（1）合理規劃緩存的失效時間；

（2）合理評估資料庫的負載壓力；

（3）對資料庫進行過載保護或應用層限流；

（4）多級緩存設計，緩存高可用。

4、緩存穿透

緩存一般是Key，value方式存在，當某一個Key不存在時會查詢資料庫，假如這個Key，一直不存在，則會頻繁的請求資料庫，對資料庫造成通路壓力。

解決方法：

（1）對結果為空的資料也進行緩存，當此key有資料後，清理緩存；

（2）一定不存在的key，采用布隆過濾器，建立一個大的Bitmap中，查詢時通過該bitmap過濾。