1. 程式人生 > >大型網站架構系列:緩存在分布式系統中的應用(二)

大型網站架構系列:緩存在分布式系統中的應用(二)

內存空間 設備 keep 訪問速度 整數 存儲方式 統一 客戶端 物理內存

原文:大型網站架構系列:緩存在分布式系統中的應用(二)

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

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

本次分享大綱

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

四、分布式緩存

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常用數據類型

1、String

  常用命令:set,get,decr,incr,mget 。

  應用場景:String是最常用的一種數據類型,與Memcache的key value存儲方式類似。

  實現方式:String在redis內部存儲默認就是一個字符串,被redisObject所引用,當遇到incr,decr等操作時會轉成數值型進行計算,此時redisObject的encoding字段為int。

2、Hash

  常用命令:hget,hset,hgetall 。

  應用場景:以存儲一個用戶信息對象數據,為例:

技術分享圖片

  實現方式:

  Redis Hash對應的Value,內部實際就是一個HashMap,實際這裏會有2種不同實現。

(1) Hash的成員比較少時Redis為了節省內存會采用類似一維數 組的方式來緊湊存儲,而不會采用真正的HashMap結構,對應的value redisObject的encoding為zipmap;

(2) 當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。

  3、List

  常用命令:lpush,rpush,lpop,rpop,lrange。

  應用場景:

  Redis list的應用場景非常多,也是Redis最重要的數據結構之一,比如twitter的關註列表,粉絲列表等都可以用Redis的list結構來實現。

  實現方式:

  Redis list的實現為一個雙向鏈表,可以支持反向查找和遍歷,方便操作。不過帶來了部分額外的內存開銷,Redis內部的很多實現,包括發送緩沖隊列等也都是用的這個數據結構。

  4、Set

  常用命令:sadd,spop,smembers,sunion。

  應用場景:

   Redis set對外提供的功能與list類似是一個列表的功能,特殊之處在於set是可以自動排重的,當你需要存儲一個列表數據,又不希望出現重復數據時,set 是一個很好的選擇,並且set提供了判斷某個成員是否在一個set集合內的重要接口,這個也是list所不能提供的。

  實現方式:

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

  5、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有專門線程,清除緩存數據;

五、本地緩存

本地緩存是指應用內部的緩存,標準的分布式系統,一般有多級緩存構成。本地緩存是離應用最近的緩存,一般可以將數據緩存到硬盤或內存。

3.1硬盤緩存

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

3.2 內存緩存

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

六、緩存架構示例

技術分享圖片

職責劃分:

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

請求過程:

(1) 瀏覽器向客戶端發起請求,如果CDN有緩存則直接返回;

(2) 如果CDN無緩存,則訪問反向代理服務器;

(3) 如果反向代理服務器有緩存則直接返回;

(4) 如果反向代理服務器無緩存或動態請求,則訪問應用服務器;

(5) 應用服務器訪問本地緩存;如果有緩存,則返回代理服務器,並緩存數據;(動態請求不緩存)

(6) 如果本地緩存無數據,則讀取分布式緩存;並返回應用服務器;應用服務器將數據緩存到本地緩存(部分);

(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

八、本次分享總結

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

我們的分享只是介紹一下知識結構,希望可以起到一個拋磚引玉的作用。因為,每個知識點都有一些細化的地方,需要學習的知識點很多,需要大家不斷深入學習。也歡迎大家把好的內容,即時的分享到群內(知識鏈接或參加周知識分享,參加周知識分享的同學可以直接聯系我哈~~)

大型網站架構系列:緩存在分布式系統中的應用(二)