緩存在分佈式系統中的應用

1、緩存概述

緩存是分佈式系統中的重要組件，主要解決高併發，大數據場景下，熱點數據訪問的性能問題。提供高性能的數據快速訪問。

1.1緩存的原理

（1）       將數據寫入/讀取速度更快的存儲（設備）；

（2）       將數據緩存到離應用最近的位置；

（3）       將數據緩存到離用戶最近的位置。

1.2緩存分類

在分佈式系統中，緩存的應用很是普遍，從部署角度有如下幾個方面的緩存應用。

（1）       CDN緩存；

（2）       反向代理緩存；

（3）       分佈式Cache；

（4）       本地應用緩存；

1.3緩存媒介

經常使用中間件：Varnish，Ngnix，Squid，Memcache，Redis，Ehcache等；

緩存的內容：文件，數據，對象；

緩存的介質：CPU，內存（本地，分佈式），磁盤（本地，分佈式）

1.3緩存設計

緩存設計須要解決如下幾個問題：

（1）       緩存什麼？

哪些數據須要緩存：1.熱點數據；2.靜態資源；

（2）       緩存的位置？

CDN，反向代理，分佈式緩存服務器，本機（內存，硬盤）

（3）       如何緩存的問題？

• 過時策略

1.固定時間：好比指定緩存的時間是30分鐘；

2.相對時間：好比最近10分鐘內沒有訪問的數據；

• 同步機制

1. 實時寫入；（推）
2. 異步刷新；（推拉）

2、CDN緩存

CDN主要解決將數據緩存到離用戶最近的位置，通常緩存靜態資源文件（頁面，腳本，圖片，視頻，文件等）。國內網絡異常複雜，跨運營商的網絡訪問會 很慢。爲了解決跨運營商或各地用戶訪問問題，能夠在重要的城市，部署CDN應用。使用戶就近獲取所需內容，下降網絡擁塞，提升用戶訪問響應速度和命中率。

2.1CND原理

CDN的基本原理是普遍採用各類緩存服務器，將這些緩存服務器分佈到用戶訪問相對集中的地區或網絡中，在用戶訪問網站時，利用全局負載技術將用戶的訪問指向距離最近的工做正常的緩存服務器上，由緩存服務器直接響應用戶請求。

（1）       未部署CDN應用前

 

網絡請求路徑：

請求：本機網絡（局域網）——》運營商網絡——》應用服務器機房

響應：應用服務器機房——》運營商網絡——》本機網絡（局域網）

在不考慮複雜網絡的狀況下，從請求到響應須要通過3個節點，6個步驟完成一次用戶訪問操做。

（2）       部署CDN應用後

網絡路徑：

請求：本機網絡（局域網）——》運營商網絡

響應：運營商網絡——》本機網絡（局域網）

在不考慮複雜網絡的狀況下，從請求到響應須要通過2個節點，2個步驟完成一次用戶訪問操做。

與不部署CDN服務相比，減小了1個節點，4個步驟的訪問。極大的提升的系統的響應速度。

2.2 CDN優缺點

（1）優勢（摘自百度百科）

一、本地Cache加速：提高訪問速度，尤爲含有大量圖片和靜態頁面站點；

二、鏡像服務：消除了不一樣運營商之間互聯的瓶頸形成的影響，實現了跨運營商的網絡加速，保證不一樣網絡中的用戶都能獲得良好的訪問質量；

三、遠程加速：遠程訪問用戶根據DNS負載均衡技術智能自動選擇Cache服務器，選擇最快的Cache服務器，加快遠程訪問的速度；

四、帶寬優化：自動生成服務器的遠程Mirror（鏡像）cache服務器，遠程用戶訪問時從cache服務器上讀取數據，減小遠程訪問的帶寬、分擔網絡流量、減輕原站點WEB服務器負載等功能。

五、集羣抗攻擊：普遍分佈的CDN節點加上節點之間的智能冗餘機制，能夠有效地預防黑客入侵以及下降各類D.D.o.S攻擊對網站的影響，同時保證較好的服務質量。

（2）缺點

1.動態資源緩存，須要注意實時性；

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

 

2.如何保證數據的一致性和實時性須要權衡考慮；

解決：

1. 設置緩存失效時間（1個小時，最終一致性）；
2. 數據版本號；

2.3CND架構參考

摘自《雲宙視頻CDN系統》

  

2.4 CND技術實踐

         目前，中小型互聯網公司，綜合成本考慮，通常租用第三方CDN服務，大型互聯網公司，採用自建或第三方結合的方式。好比淘寶剛開始使用第三方的，當流量很大後，第三方公司沒法支撐其CDN流量，淘寶最後採用自建CDN的方式實現。

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

 

3、反向代理緩存

反向代理是指在網站服務器機房部署代理服務器，實現負載均衡，數據緩存，安全控制等功能。

3.1緩存原理

反向代理位於應用服務器機房，處理全部對WEB服務器的請求。若是用戶請求的頁面在代理服務器上有緩衝的話，代理服務器直接將緩衝內容發送給用戶。 若是沒有緩衝則先向WEB服務器發出請求，取回數據，本地緩存後再發送給用戶。經過下降向WEB服務器的請求數，從而下降了WEB服務器的負載。

 

         反向代理通常緩存靜態資源，動態資源轉發到應用服務器處理。經常使用的緩存應用服務器有Varnish，Ngnix，Squid。

3.2 Squid示例

Squid 反向代理通常只緩存靜態資源，動態程序默認不緩存。根據從 WEB 服務器返回的 HTTP 頭標記來緩衝靜態頁面。有四個最重要 HTTP 頭標記：

Last-Modified: 告訴反向代理頁面什麼時間被修改

Expires: 告訴反向代理頁面什麼時間應該從緩衝區中刪除

Cache-Control: 告訴反向代理頁面是否應該被緩衝

Pragma: 用來包含實現特定的指令，最經常使用的是 Pragma:no-cache

 

Squid 反向代理加速網站實例

（1）       經過DNS的輪詢技術，將客戶端的請求分發給其中一臺 Squid 反向代理服務器處理；

（2）       若是這臺 Squid 緩存了用戶的請求資源，則將請求的資源直接返回給用戶；

（3）       不然這臺 Squid 將沒有緩存的請求根據配置的規則發送給鄰居 Squid 和後臺的 WEB 服務器處理；

（4）       這樣既減輕後臺 WEB 服務器的負載，又提升整個網站的性能和安全性。

 

3.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，通常做爲反向代理使用，能夠實現簡單的緩存。

 

4、分佈式緩存

CDN,反向代理緩存，主要解決靜態文件，或用戶請求資源的緩存，數據源通常爲靜態文件或動態生成的文件（有緩存頭標識）。

分佈式緩存，主要指緩存用戶常常訪問數據的緩存，數據源爲數據庫。通常起到熱點數據訪問和減輕數據庫壓力的做用。

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

4.1Memcache

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對空間是否過 期，這樣可減輕服務器的負載。

 

4.1.1Memcache工做原理

 

MemCache的工做流程以下：

（1）              先檢查客戶端的請求數據是否在memcached中，若有，直接把請求數據返回，再也不對數據庫進行任何操做；

（2）              若是請求的數據不在memcached中，就去查數據庫，把從數據庫中獲取的數據返回給客戶端，同時把數據緩存一份到memcached中（memcached客戶端不負責，須要程序實現）；

（3）              每次更新數據庫的同時更新memcached中的數據，保證一致性；

（4）              當分配給memcached內存空間用完以後，會使用LRU（Least Recently Used，最近最少使用）策略加上到期失效策略，失效數據首先被替換，而後再替換掉最近未使用的數據。

4.1.2Memcache集羣

memcached 雖然稱爲 「 分佈式 」 緩存服務器，但服務器端並無 「 分佈式 」 功能。每一個服務器都是徹底獨立和隔離的服務。 memcached 的分佈式，是由客戶端程序實現的。

當向memcached集羣存入/取出key value時，memcached客戶端程序根據必定的算法計算存入哪臺服務器，而後再把key value值存到此服務器中。

存取數據分二步走，第一步，選擇服務器，第二步存取數據。

分佈式算法(Consistent Hashing)：

選擇服務器算法有兩種，一種是根據餘數來計算分佈，另外一種是根據散列算法來計算分佈。
餘數算法：
    先求得鍵的整數散列值，再除以服務器臺數，根據餘數肯定存取服務器。

優勢：計算簡單，高效；

缺點：在memcached服務器增長或減小時，幾乎全部的緩存都會失效。
散列算法：（一致性Hash）
    先算出memcached服務器的散列值，並將其分佈到0到2的32次方的圓上，而後用一樣的方法算出存儲數據的鍵的散列值並映射至圓上，最後從數據映射 到的位置開始順時針查找，將數據保存到查找到的第一個服務器上，若是超過2的32次方，依然找不到服務器，就將數據保存到第一臺memcached服務器 上。

 

若是添加了一臺memcached服務器，只在圓上增長服務器的逆時針方向的第一臺服務器上的鍵會受到影響。

一致性Hash算法：解決了餘數算法增長節點命中大幅額度下降的問題，理論上，插入一個實體節點，平均會影響到：虛擬節點數 /2 的節點數據的命中。

4.2Redis

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）。

4.2.1Redis經常使用數據類型

一、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,使用跳躍表的結構能夠得到比較高的查找效率，而且在實現上比較簡單。

4.2.2Redis集羣

（1）經過keepalived實現的高可用方案

 

切換流程：

1. 當Master掛了後，VIP漂移到Slave；Slave 上keepalived 通知redis 執行：slaveof no one ,開始提供業務

2. 當Master起來後，VIP 地址不變，Master的keepalived 通知redis 執行slaveof slave IP host ，開始做爲從同步數據

3. 依次類推

 

主從同時Down機狀況：

1. 非計劃性，不作考慮，通常也不會存在這種問題

2.、計劃性重啓，重啓以前經過運維手段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節點集羣上，不須要額外設備

4.3Memcache與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有專門線程，清除緩存數據；

 

5、本地緩存

本地緩存是指應用內部的緩存，標準的分佈式系統，通常有多級緩存構成。本地緩存是離應用最近的緩存，通常能夠將數據緩存到硬盤或內存。

3.1硬盤緩存

         將數據緩存到硬盤到，讀取時從硬盤讀取。原理是直接讀取本機文件，減小了網絡傳輸消耗，比經過網絡讀取數據庫速度更快。能夠應用在對速度要求不是很高，但須要大量緩存存儲的場景。

3.2 內存緩存

直接將數據存儲到本機內存中，經過程序直接維護緩存對象，是訪問速度最快的方式。

6、緩存架構示例

 

職責劃分：

• CDN：存放HTML,CSS,JS等靜態資源；
• 反向代理：動靜分離，只緩存用戶請求的靜態資源；
• 分佈式緩存：緩存數據庫中的熱點數據；
• 本地緩存：緩存應用字典等經常使用數據；

 

請求過程：

（1）       瀏覽器向客戶端發起請求，若是CDN有緩存則直接返回；

（2）       若是CDN無緩存，則訪問反向代理服務器；

（3）       若是反向代理服務器有緩存則直接返回；

（4）       若是反向代理服務器無緩存或動態請求，則訪問應用服務器；

（5）       應用服務器訪問本地緩存；若是有緩存，則返回代理服務器，並緩存數據；（動態請求不緩存）

（6）       若是本地緩存無數據，則讀取分佈式緩存；並返回應用服務器；應用服務器將數據緩存到本地緩存（部分）；

（7）       若是分佈式緩存無數據，則應用程序讀取數據庫數據，並放入分佈式緩存；

 

 

數據一致性

緩存是在數據持久化以前的一個節點，主要是將熱點數據放到離用戶最近或訪問速度更快的介質中，加快數據的訪問，減少響應時間。

由於緩存屬於持久化數據的一個副本，所以不可避免的會出現數據不一致問題。致使髒讀或讀不到數據的狀況。數據不一致，通常是由於網絡不穩定或節點故障致使。根據數據的操做順序，主要有如下幾種狀況。

2.1場景介紹

（1）先寫緩存，再寫數據庫

         以下圖：

 

假如緩存寫成功，但寫數據庫失敗或響應延遲，則下次讀取（併發讀）緩存時，就出現髒讀；

 

（2）先寫數據庫，再寫緩存

         以下圖：

        

         假如寫數據庫成功，但寫緩存失敗，則下次讀取（併發讀）緩存時，則讀不到數據；

 

（3）緩存異步刷新

         指數據庫操做和寫緩存不在一個操做步驟中，好比在分佈式場景下，沒法作到同時寫緩存或須要異步刷新（補救措施）時候。

 

         此種狀況，主要考慮數據寫入和緩存刷新的時效性。好比多久內刷新緩存，不影響用戶對數據的訪問。

2.2解決方法

第一個場景：

這個寫緩存的方式，自己就是錯誤的，須要改成先寫持久化介質，再寫緩存的方式。

第二個場景：

（1）根據寫入緩存的響應來進行判斷，若是緩存寫入失敗，則回滾數據庫操做；此種方法增長了程序的複雜度，不建議採用；

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

第三個場景：

（1）首先肯定，哪些數據適合此類場景；

（2）根據經驗值肯定合理的數據不一致時間，用戶數據刷新的時間間隔；

2.3 其餘方法

（1）超時：設置合理的超時時間；

（2）刷新：定時刷新必定範圍內（根據時間，版本號）的數據；

 

         以上是簡化數據讀寫場景，實際中會分爲：

         （1）緩存與數據庫之間的一致性；

         （2）多級緩存以前的一致性；

         （3）緩存副本以前的一致性。

緩存高可用

業界有兩種理論，第一套緩存就是緩存，臨時存儲數據的，不須要高可用。第二種緩存逐步演化爲重要的存儲介質，須要作高可用。

本人的見解是，緩存是否高可用，須要根據實際的場景而定。臨界點是是否對後端的數據庫形成影響。

具體的決策依據須要根據，集羣的規模（數據，緩存），成本（服務器，運維），系統性能（併發量，吞吐量，響應時間）等方面綜合評價。

3.1解決方法

         緩存的高可用，通常經過分佈式和複製實現。分佈式實現數據的海量緩存，複製實現緩存數據節點的高可用。架構圖以下：

        

         其中，分佈式採用一致性Hash算法，複製採用異步複製。

3.2其餘方法

（1）複製雙寫：緩存節點的複製，由異步改成雙寫，只有兩份都寫成功，纔算成功。

（2）虛擬層：一致性Hash存在，假如其中一個HASH環不可用，數據會寫入臨近的環，當HASH可用時，數據又寫入正常的HASH環，會致使數據偏移問題。這種狀況，能夠考慮在HASH環前面加一個虛擬層實現。

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

 

         方式不少，須要根據業務場景靈活選擇。

緩存雪崩

         雪崩是指當大量緩存失效時，致使大量的請求訪問數據庫，致使數據庫服務器，沒法抗住請求或掛掉的狀況。

         解決方法：

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

         （2）合理評估數據庫的負載壓力；

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

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

緩存穿透

         緩存通常是Key，value方式存在，當某一個Key不存在時會查詢數據庫，假如這個Key，一直不存在，則會頻繁的請求數據庫，對數據庫形成訪問壓力。

解決方法：

（1）對結果爲空的數據也進行緩存，當此key有數據後，清理緩存；

（2）必定不存在的key，採用布隆過濾器，創建一個大的Bitmap中，查詢時經過該bitmap過濾；