分布式緩存

CDN,反向代理緩存，主要解決靜態(tài)文件，或用戶請求資源的緩存，數(shù)據(jù)源一般為靜態(tài)文件或動態(tài)生成的文件（有緩存頭標識）。

分布式緩存，主要指緩存用戶經(jīng)常訪問數(shù)據(jù)的緩存，數(shù)據(jù)源為數(shù)據(jù)庫。一般起到熱點數(shù)據(jù)訪問和減輕數(shù)據(jù)庫壓力的作用。

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

1.1Memcache

Memcache是一個高性能，分布式內(nèi)存對象緩存系統(tǒng)，通過在內(nèi)存里維護一個統(tǒng)一的巨大的hash表，它能夠用來存儲各種格式的數(shù)據(jù)，包括圖像、視頻、文件以及數(shù)據(jù)庫檢索的結(jié)果等。簡單的說就是將數(shù)據(jù)調(diào)用到內(nèi)存中，然后從內(nèi)存中讀取，從而大大提高讀取速度。

Memcache特性：

使用物理內(nèi)存作為緩存區(qū)，可獨立運行在服務器上。每個進程最大2G，如果想緩存更多的數(shù)據(jù)，可以開辟更多的memcache進程（不同端口）或者使用分布式memcache進行緩存，將數(shù)據(jù)緩存到不同的物理機或者虛擬機上。

使用key-value的方式來存儲數(shù)據(jù)，這是一種單索引的結(jié)構(gòu)化數(shù)據(jù)組織形式，可使數(shù)據(jù)項查詢時間復雜度為O(1)。

協(xié)議簡單：基于文本行的協(xié)議，直接通過telnet在memcached服務器上可進行存取數(shù)據(jù)操作，簡單，方便多種緩存參考此協(xié)議；

基于libevent高性能通信：Libevent是一套利用C開發(fā)的程序庫，它將BSD系統(tǒng)的kqueue,Linux系統(tǒng)的epoll等事件處理功能封裝成一個接口，與傳統(tǒng)的select相比，提高了性能。

內(nèi)置的內(nèi)存管理方式：所有數(shù)據(jù)都保存在內(nèi)存中，存取數(shù)據(jù)比硬盤快，當內(nèi)存滿后，通過LRU算法自動刪除不使用的緩存，但沒有考慮數(shù)據(jù)的容災問題，重啟服務，所有數(shù)據(jù)會丟失。

分布式：各個memcached服務器之間互不通信，各自獨立存取數(shù)據(jù)，不共享任何信息 下載地址。服務器并不具有分布式功能，分布式部署取決于memcache客戶端。

緩存策略：Memcached的緩存策略是LRU（最近最少使用）到期失效策略。在memcached內(nèi)存儲數(shù)據(jù)項時，可以指定它在緩存的失效時間，默認為永久。當memcached服務器用完分配的內(nèi)時，失效的數(shù)據(jù)被首先替換，然后也是最近未使用的數(shù)據(jù)。在LRU中，memcached使用的是一種Lazy Expiration策略，自己不會監(jiān)控存入的key/vlue對是否過期，而是在獲取key值時查看記錄的時間戳，檢查key/value對空間是否過期，這樣可減輕服務器的負載。

1.1.1Memcache工作原理

MemCache的工作流程如下：

先檢查客戶端的請求數(shù)據(jù)是否在memcached中，如有，直接把請求數(shù)據(jù)返回，不再對數(shù)據(jù)庫進行任何操作；

如果請求的數(shù)據(jù)不在memcached中，就去查數(shù)據(jù)庫，把從數(shù)據(jù)庫中獲取的數(shù)據(jù)返回給客戶端，同時把數(shù)據(jù)緩存一份到memcached中（memcached客戶端不負責，需要程序?qū)崿F(xiàn)）；

每次更新數(shù)據(jù)庫的同時更新memcached中的數(shù)據(jù)，保證一致性；

當分配給memcached內(nèi)存空間用完之后，會使用LRU（Least Recently Used，最近最少使用）策略加上到期失效策略，失效數(shù)據(jù)首先被替換，然后再替換掉最近未使用的數(shù)據(jù)。

1.1.2Memcache下載地址集群

memcached 雖然稱為 “ 分布式 ” 緩存服務器，但服務器端并沒有 “ 分布式 ” 功能。每個服務器都是完全獨立和隔離的服務。 memcached 的分布式，是由客戶端程序?qū)崿F(xiàn)的。

當向memcached集群存入/取出key value時，memcached客戶端程序根據(jù)一定的算法計算存入哪臺服務器，然后再把key value值存到此服務器中。

存取數(shù)據(jù)分二步走，第一步，選擇服務器，第二步存取數(shù)據(jù)。

分布式算法(Consistent Hashing下載地址)：

選擇服務器算法有兩種，一種是根據(jù)余數(shù)來計算分布，另一種是根據(jù)散列算法來計算分布。

余數(shù)算法：

先求得鍵的整數(shù)散列值，再除以服務器臺數(shù)，根據(jù)余數(shù)確定存取服務器。

優(yōu)點：計算簡單，高效；

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

散列算法：（一致性Hash）

先算出memcached服務器的散列值，并將其分布到0到2的32次方的圓上，然后用同樣的方法算出存儲數(shù)據(jù)的鍵的散列值并映射至圓上，最后從數(shù)據(jù)映射到的位置開始順時針查找，將數(shù)據(jù)保存到查找到的第一個服務器上，如果超過2的32次方，依然找不到服務器，就將數(shù)據(jù)保存到第一臺memcached服務器上。

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

一致性Hash算法：解決了余數(shù)算法增加節(jié)點命中大幅額度降低的問題，理論上，插入一個實體節(jié)點，平均會影響到：虛擬節(jié)點數(shù) /2 的節(jié)點數(shù)據(jù)的命中。

1.2Redis

Redis 是一個開源（BSD許可）的，基于內(nèi)存的，多數(shù)據(jù)結(jié)構(gòu)存儲系統(tǒng)?？梢杂米鲾?shù)據(jù)庫、緩存和消息中間件。 支持多種類型的數(shù)據(jù)結(jié)構(gòu)，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 與范圍查詢， bitmaps， hyperloglogs 和 地理空間（geospatial） 索引半徑查詢。

內(nèi)置了 復制（replication），LUA腳本（Lua scripting）， LRU驅(qū)動事件（LRU eviction），事務（transactions） 和不同級別的 磁盤持久化（persistence）， 并通過 Redis哨兵（Sentinel）和自動分區(qū)（Cluster）提供高可用性（high availability）。

1.2.1Redis常用數(shù)據(jù)類型

1、String

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

應用場景：String是最常用的一種數(shù)據(jù)類型，與Memcache的key value存儲方式類似。

實現(xiàn)方式：String在redis內(nèi)部存儲默認就是一個字符串，被redisObject所引用，當遇到incr,decr等操作時會轉(zhuǎn)成數(shù)值型進行計算，此時redisObject的encoding字段為int。

2、Hash

常用命令：hget,hset,hgetall 。

應用場景：以存儲一個用戶信息對象數(shù)據(jù)，為例：

實現(xiàn)方式：

Redis Hash對應的Value，內(nèi)部實際就是一個HashMap，實際這里會有2種不同實現(xiàn)。

Hash的成員比較少時Redis為了節(jié)省內(nèi)存會采用類似一維數(shù) 組的方式來緊湊存儲，而不會采用真正的HashMap結(jié)構(gòu)，對應的value redisObject的encoding為zipmap；

當成員數(shù)量增大時會自動轉(zhuǎn)成真正的HashMap,此時encoding為ht下載地址。

3、List

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

應用場景：

Redis list的應用場景非常多，也是Redis最重要的數(shù)據(jù)結(jié)構(gòu)之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結(jié)構(gòu)來實現(xiàn)。

實現(xiàn)方式：

Redis list的實現(xiàn)為一個雙向鏈表，可以支持反向查找和遍歷，方便操作。不過帶來了部分額外的內(nèi)存開銷，Redis內(nèi)部的很多實現(xiàn)，包括發(fā)送緩沖隊列等也都是用的這個數(shù)據(jù)結(jié)構(gòu)。

4、Set

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

應用場景：

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

實現(xiàn)方式：

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

5、Sorted set

常用命令：zadd,zrange,zrem,zcard；

使用場景：

Redis sorted set的使用場景與set類似，區(qū)別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優(yōu)先級(score)的參數(shù)來為成員排序，并且是插入有序的，即自動排序。當你需要一個有序的并且不重復的集合列表，可以選擇sorted set數(shù)據(jù)結(jié)構(gòu)，比如twitter 的public timeline可以以發(fā)表時間作為score來存儲，這樣獲取時就是自動按時間排好序的。

實現(xiàn)方式：

Redis sorted set的內(nèi)部使用HashMap和跳躍表(SkipList)來保證數(shù)據(jù)的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表里存放的 是所有的成員，排序依據(jù)是HashMap里存的score,使用跳躍表的結(jié)構(gòu)可以獲得比較高的查找效率，并且在實現(xiàn)上比較簡單下載地址。

1.2.2Redis集群

（1）通過keepalived實現(xiàn)的高可用方案

切換流程：

當Master掛了后，VIP漂移到Slave；Slave 上keepalived 通知redis 執(zhí)行：slaveof no one ,開始提供業(yè)務

當Master起來后，VIP 地址不變，Master的keepalived 通知redis 執(zhí)行slaveof slave IP host ，開始作為從同步數(shù)據(jù)

依次類推

針對上面的技術(shù)我特意整理了一下，有很多技術(shù)不是靠幾句話能講清楚，所以干脆找朋友錄制了一些視頻，很多問題其實答案很簡單，但是背后的思考和邏輯不簡單，要做到知其然還要知其所以然。如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java進階群：680130298，群里有阿里大牛直播講解技術(shù)，以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費分享給大家。

主從同時Down機情況：

1.非計劃性，不做考慮，一般也不會存在這種問題

2.計劃性重啟，重啟之前通過運維手段SAVE DUMP 主庫數(shù)據(jù)；需要注意順序：

3.關閉其中一臺機器上所有redis，是得master全部切到另外一臺機器（多實例部署，單機上既有主又有從的情況）；并關閉機器

4.依次dump主上redis服務

5.關閉主

6.啟動主，并等待數(shù)據(jù)load完畢

7.啟動從

8.刪除DUMP 文件（避免重啟加載慢）

（2）使用Twemproxy 實現(xiàn)集群方案

由twitter開源的c版本proxy，同時支持memcached和redis，目前最新版本為：0.2.4，持續(xù)開發(fā)中;用它主要減少前端與緩存服務間網(wǎng)絡連接數(shù)。

特點：快、輕量級、減少后端Cache Server連接數(shù)、易配置、支持ketama、modula、random、常用hash 分片算法。

這里使用keepalived實現(xiàn)高可用主備方案，解決proxy單點問題；

優(yōu)點：

1. 對于客戶端而言，redis集群是透明的，客戶端簡單，遍于動態(tài)擴容

2. Proxy為單點、處理一致性hash時，集群節(jié)點可用性檢測不存在腦裂問題

3. 高性能，CPU密集型，而redis節(jié)點集群多CPU資源冗余，可部署在redis節(jié)點集群上，不需要額外設備

1.3Memcache與Redis的比較

（1）數(shù)據(jù)結(jié)構(gòu)：Memcache只支持key value存儲方式，Redis支持更多的數(shù)據(jù)類型，比如Key value，hash，list，set，zset；

（2）多線程：Memcache支持多線程，redis支持單線程；CPU利用方面Memcache優(yōu)于redis；

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

（4）內(nèi)存利用率：memcache高，redis低（采用壓縮的情況下比memcache高）；

（5）過期策略：memcache過期后，不刪除緩存，會導致下次取數(shù)據(jù)數(shù)據(jù)的問題，Redis有專門線程，清除緩存數(shù)據(jù)；

本地緩存

本地緩存是指應用內(nèi)部的緩存，標準的分布式系統(tǒng)，一般有多級緩存構(gòu)成。本地緩存是離應用最近的緩存，一般可以將數(shù)據(jù)緩存到硬盤或內(nèi)存。

1.1硬盤緩存

將數(shù)據(jù)緩存到硬盤到，讀取時從硬盤讀取。原理是直接讀取本機文件，減少了網(wǎng)絡傳輸消耗，比通過網(wǎng)絡讀取數(shù)據(jù)庫速度更快?？梢詰迷趯λ俣纫蟛皇呛芨撸枰罅烤彺娲鎯Φ膱鼍?。

1.2 內(nèi)存緩存

直接將數(shù)據(jù)存儲到本機內(nèi)存中，通過程序直接維護緩存對象，是訪問速度最快的方式。

緩存架構(gòu)示例

職責劃分：

CDN：存放HTML,CSS,JS等靜態(tài)資源；

反向代理：動靜分離，只緩存用戶請求的靜態(tài)資源；

分布式緩存：緩存數(shù)據(jù)庫中的熱點數(shù)據(jù)；

本地緩存：緩存應用字典等常用數(shù)據(jù)；

請求過程：

（1） 瀏覽器向客戶端發(fā)起請求，如果CDN有緩存則直接返回；

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

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

（4） 如果反向代理服務器無緩存或動態(tài)請求，則訪問應用服務器；

（5） 應用服務器訪問本地緩存；如果有緩存，則返回代理服務器，并緩存數(shù)據(jù)；（動態(tài)請求不緩存）

（6） 如果本地緩存無數(shù)據(jù)，則讀取分布式緩存；并返回應用服務器；應用服務器將數(shù)據(jù)緩存到本地緩存（部分）；

（7） 如果分布式緩存無數(shù)據(jù)，則應用程序讀取數(shù)據(jù)庫數(shù)據(jù)，并放入分布式緩存