大型網站架構系列：緩存在分佈式系統中的應用（二）

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

本文是緩存在分佈式應用第二篇文章，介紹分佈式緩存，Memcache，Redis，本地緩存（硬盤緩存，內存緩存）以及緩存在分佈式系統中的架構示例。本文主要是本身的學習總結和網絡文章摘錄，供學習之用。

本次分享大綱

1. 緩存概述
2. CDN緩存
3. 反向代理緩存
4. 分佈式緩存
5. 本地緩存
6. 緩存架構示例
7. 參考資料
8. 分享總結

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）       若是分佈式緩存無數據，則應用程序讀取數據庫數據，並放入分佈式緩存；

7、參考資料

如下是本次分享參考的資料和推薦你們參考的資料。

7.1 CND資料

淘寶CDN系統架構:

http://blog.sina.com.cn/s/blog_4adf62ab0100tjld.html

天貓瀏覽型應用的CDN靜態化架構演變【經典】

http://kb.cnblogs.com/page/199235/

ChinaCache CDN簡介

http://wenku.baidu.com/link?url=oAT72EEemiRnH2Iy2Bg4phHXsRmSlN_WHd4jH7kiDb4TqYMIyCR3v7oUhKMj9GqN7W1qwu1K4tQNyD6NKtuQ7o7aT3JIujcd_QjRf34BtKO

7.2反向代理資料

squid反向代理：http://my.oschina.net/u/267384/blog/173149

7.3分佈式緩存資料

Memcache知識點梳理：http://369369.blog.51cto.com/319630/833234/

memcache學習總結-wish

http://wenku.baidu.com/link?url=Qx4JYNgBJN0pqREImt1mZr625sj03AJoCWsIwDZlFQfi1iyejCb0feqG0gov3FLcrtEioJ3fU-4zj0H6VKPXWONYVZaAyX-HPWXDbRxyqF7

memcache 分佈式，算法實現

http://1006836709.iteye.com/blog/1997381

 

分析Redis架構設計

http://blog.csdn.net/a600423444/article/details/8944601

Redis 集羣方案：http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html

Redis經常使用數據類型：http://blog.sina.com.cn/s/blog_7f37ddde0101021q.html

 

8、本次分享總結

以上是本週的分享，主要講解了緩存在分佈式系統中的典型應用場景，CDN，反向代理緩存，分佈式緩存（Memcache,Redis），本地緩存（硬盤，內存）。最後總體分享了以上幾種緩存在架構中的使用。

咱們的分享只是介紹一下知識結構，但願能夠起到一個拋磚引玉的做用。由於，每一個知識點都有一些細化的地方，須要學習的知識點不少，須要你們不斷深刻學習。也歡迎你們把好的內容，即時的分享到羣內（知識連接或參加周知識分享，參加周知識分享的同窗能夠直接聯繫我哈~~）