緩存是分布式系統(tǒng)中的重要組件，主要解決高并發(fā)，大數(shù)據(jù)場景下，熱點數(shù)據(jù)訪問的性能問題。提供高性能的數(shù)據(jù)快速訪問。

[[252441]]

一、緩存概述

緩存是分布式系統(tǒng)中的重要組件，主要解決高并發(fā)，大數(shù)據(jù)場景下，熱點數(shù)據(jù)訪問的性能問題。提供高性能的數(shù)據(jù)快速訪問。

1.1緩存的原理

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

（2） 將數(shù)據(jù)緩存到離應用最近的位置；

（3） 將數(shù)據(jù)緩存到離用戶最近的位置。

1.2緩存分類

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

（1） CDN緩存；

（2） 反向代理緩存；

（3） 分布式Cache；

（4） 本地應用緩存；

1.3緩存媒介

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

緩存的內(nèi)容：文件，數(shù)據(jù)，對象；

緩存的介質(zhì)：CPU，內(nèi)存（本地，分布式），磁盤（本地，分布式）

1.4緩存設計

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

（1） 緩存什么？

哪些數(shù)據(jù)需要緩存：1.熱點數(shù)據(jù)；2.靜態(tài)資源；

（2） 緩存的位置？

CDN，反向代理，分布式緩存服務器，本機（內(nèi)存，硬盤）

（3） 如何緩存的問題？

過期策略

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

2.相對時間：比如最近10分鐘內(nèi)沒有訪問的數(shù)據(jù)；

同步機制

實時寫入；（推）

異步刷新；（推拉）

二、CDN緩存

CDN主要解決將數(shù)據(jù)緩存到離用戶最近的位置，一般緩存靜態(tài)資源文件（頁面，腳本，圖片，視頻，文件等）。國內(nèi)網(wǎng)絡異常復雜，跨運營商的網(wǎng)絡訪問會很慢。為了解決跨運營商或各地用戶訪問問題，可以在重要的城市，部署CDN應用。使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡擁塞，提高用戶訪問響應速度和命中率。

2.1CND原理

CDN的基本原理是廣泛采用各種緩存服務器，將這些緩存服務器分布到用戶訪問相對集中的地區(qū)或網(wǎng)絡中，在用戶訪問網(wǎng)站時，利用全局負載技術(shù)將用戶的訪問指向距離最近的工作正常的緩存服務器上，由緩存服務器直接響應用戶請求。

（1） 未部署CDN應用前

網(wǎng)絡請求路徑：

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

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

在不考慮復雜網(wǎng)絡的情況下，從請求到響應需要經(jīng)過3個節(jié)點，6個步驟完成一次用戶訪問操作。

（2） 部署CDN應用后

網(wǎng)絡路徑：

請求：本機網(wǎng)絡（局域網(wǎng)）——》運營商網(wǎng)絡

響應：運營商網(wǎng)絡——》本機網(wǎng)絡（局域網(wǎng)）

在不考慮復雜網(wǎng)絡的情況下，從請求到響應需要經(jīng)過2個節(jié)點，2個步驟完成一次用戶訪問操作。

與不部署CDN服務相比，減少了1個節(jié)點，4個步驟的訪問。極大的提高的系統(tǒng)的響應速度。

2.2 CDN優(yōu)缺點

（1）優(yōu)點（摘自百度百科）

1、本地Cache加速：提升訪問速度，尤其含有大量圖片和靜態(tài)頁面站點；

2、鏡像服務：消除了不同運營商之間互聯(lián)的瓶頸造成的影響，實現(xiàn)了跨運營商的網(wǎng)絡加速，保證不同網(wǎng)絡中的用戶都能得到良好的訪問質(zhì)量；

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

4、帶寬優(yōu)化：自動生成服務器的遠程Mirror（鏡像）cache服務器，遠程用戶訪問時從cache服務器上讀取數(shù)據(jù)，減少遠程訪問的帶寬、分擔網(wǎng)絡流量、減輕原站點WEB服務器負載等功能。

5、集群抗攻擊：廣泛分布的CDN節(jié)點加上節(jié)點之間的智能冗余機制，可以有效地預防黑客入侵以及降低各種D.D.o.S攻擊對網(wǎng)站的影響，同時保證較好的服務質(zhì)量。

（2）缺點

1.動態(tài)資源緩存，需要注意實時性；

解決：主要緩存靜態(tài)資源，動態(tài)資源建立多級緩存或準實時同步；

2.如何保證數(shù)據(jù)的一致性和實時性需要權(quán)衡考慮；

解決：

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

數(shù)據(jù)版本號；

2.3CND架構(gòu)參考

摘自《云宙視頻CDN系統(tǒng)》

2.4 CND技術(shù)實踐

目前，中小型互聯(lián)網(wǎng)公司，綜合成本考慮，一般租用第三方CDN服務，大型互聯(lián)網(wǎng)公司，采用自建或第三方結(jié)合的方式。比如淘寶剛開始使用第三方的，當流量很大后，第三方公司無法支撐其CDN流量，淘寶最后采用自建CDN的方式實現(xiàn)。

淘寶CDN，如下圖（來自網(wǎng)絡）：

三、反向代理緩存

反向代理是指在網(wǎng)站服務器機房部署代理服務器，實現(xiàn)負載均衡，數(shù)據(jù)緩存，安全控制等功能。

3.1緩存原理

反向代理位于應用服務器機房，處理所有對WEB服務器的請求。如果用戶請求的頁面在代理服務器上有緩沖的話，代理服務器直接將緩沖內(nèi)容發(fā)送給用戶。如果沒有緩沖則先向WEB服務器發(fā)出請求，取回數(shù)據(jù)，本地緩存后再發(fā)送給用戶。通過降低向WEB服務器的請求數(shù)，從而降低了WEB服務器的負載。

反向代理一般緩存靜態(tài)資源，動態(tài)資源轉(zhuǎn)發(fā)到應用服務器處理。常用的緩存應用服務器有Varnish，Ngnix，Squid。

3.2 Squid示例

Squid 反向代理一般只緩存靜態(tài)資源，動態(tài)程序默認不緩存。根據(jù)從 WEB 服務器返回的 HTTP 頭標記來緩沖靜態(tài)頁面。有四個最重要 HTTP 頭標記：

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

Expires: 告訴反向代理頁面什么時間應該從緩沖區(qū)中刪除

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

Pragma: 用來包含實現(xiàn)特定的指令，最常用的是 Pragma:no-cache

Squid 反向代理加速網(wǎng)站實例

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

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

（3） 否則這臺 Squid 將沒有緩存的請求根據(jù)配置的規(guī)則發(fā)送給鄰居 Squid 和后臺的 WEB 服務器處理；

（4） 這樣既減輕后臺 WEB 服務器的負載，又提高整個網(wǎng)站的性能和安全性。

3.3 代理緩存比較

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

（1） varnish和squid是專業(yè)的cache服務，nginx需要第三方模塊支持；

（2） Varnish采用內(nèi)存型緩存，避免了頻繁在內(nèi)存、磁盤中交換文件，性能比Squid高；

（3） Varnish由于是內(nèi)存cache，所以對小文件如css,js,小圖片啥的支持很棒，后端的持久化緩存可以采用的是Squid或ATS；

（4） Squid功能全而大，適合于各種靜態(tài)的文件緩存，一般會在前端掛一個HAProxy或nginx做負載均衡跑多個實例；

（5） Nginx采用第三方模塊ncache做的緩沖，性能基本達到varnish，一般作為反向代理使用，可以實現(xiàn)簡單的緩存。

四、分布式緩存

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。

4.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特性：

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

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

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

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

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

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

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

4.1.1Memcache工作原理

MemCache的工作流程如下：

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

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

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

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

4.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ù)的命中。

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

4.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)。

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

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

3、List

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

應用場景：

Redis list的應用場景非常多，也是Redis最重要的數(shù)據(jù)結(jié)構(gòu)之一，比如twitter的關(guān)注列表，粉絲列表等都可以用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)上比較簡單。

4.2.2Redis集群

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

切換流程：

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

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

3. 依次類推

主從同時Down機情況：

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

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

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

2. 依次dump主上redis服務

3. 關(guān)閉主

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

5. 啟動從

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

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

由twitter開源的c版本proxy，同時支持memcached和redis，目前最新版本為：0.2.4，持續(xù)開發(fā)中;https://github.com/twitter/twemproxy .twitter用它主要減少前端與緩存服務間網(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é)點集群上，不需要額外設備

4.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)存。

5.1硬盤緩存

將數(shù)據(jù)緩存到硬盤到，讀取時從硬盤讀取。原理是直接讀取本機文件，減少了網(wǎng)絡傳輸消耗，比通過網(wǎng)絡讀取數(shù)據(jù)庫速度更快?？梢詰迷趯λ俣纫蟛皇呛芨?，但需要大量緩存存儲的場景。

5.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ù)，并放入分布式緩存；

七、數(shù)據(jù)一致性

緩存是在數(shù)據(jù)持久化之前的一個節(jié)點，主要是將熱點數(shù)據(jù)放到離用戶最近或訪問速度更快的介質(zhì)中，加快數(shù)據(jù)的訪問，減小響應時間。

因為緩存屬于持久化數(shù)據(jù)的一個副本，因此不可避免的會出現(xiàn)數(shù)據(jù)不一致問題。導致臟讀或讀不到數(shù)據(jù)的情況。數(shù)據(jù)不一致，一般是因為網(wǎng)絡不穩(wěn)定或節(jié)點故障導致。根據(jù)數(shù)據(jù)的操作順序，主要有以下幾種情況。

7.1場景介紹

（1）先寫緩存，再寫數(shù)據(jù)庫

如下圖：

假如緩存寫成功，但寫數(shù)據(jù)庫失敗或響應延遲，則下次讀取（并發(fā)讀）緩存時，就出現(xiàn)臟讀；

（2）先寫數(shù)據(jù)庫，再寫緩存

如下圖：

假如寫數(shù)據(jù)庫成功，但寫緩存失敗，則下次讀取（并發(fā)讀）緩存時，則讀不到數(shù)據(jù)；

（3）緩存異步刷新

指數(shù)據(jù)庫操作和寫緩存不在一個操作步驟中，比如在分布式場景下，無法做到同時寫緩存或需要異步刷新（補救措施）時候。

此種情況，主要考慮數(shù)據(jù)寫入和緩存刷新的時效性。比如多久內(nèi)刷新緩存，不影響用戶對數(shù)據(jù)的訪問。

7.2解決方法

第一個場景：

這個寫緩存的方式，本身就是錯誤的，需要改為先寫持久化介質(zhì)，再寫緩存的方式。

第二個場景：

（1）根據(jù)寫入緩存的響應來進行判斷，如果緩存寫入失敗，則回滾數(shù)據(jù)庫操作；此種方法增加了程序的復雜度，不建議采用；

（2）緩存使用時，假如讀緩存失敗，先讀數(shù)據(jù)庫，再回寫緩存的方式實現(xiàn)。

第三個場景：

（1）首先確定，哪些數(shù)據(jù)適合此類場景；

（2）根據(jù)經(jīng)驗值確定合理的數(shù)據(jù)不一致時間，用戶數(shù)據(jù)刷新的時間間隔；

7.3 其他方法

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

（2）刷新：定時刷新一定范圍內(nèi)（根據(jù)時間，版本號）的數(shù)據(jù)；

以上是簡化數(shù)據(jù)讀寫場景，實際中會分為：

（1）緩存與數(shù)據(jù)庫之間的一致性；

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

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

八、緩存高可用

業(yè)界有兩種理論，第一套緩存就是緩存，臨時存儲數(shù)據(jù)的，不需要高可用。第二種緩存逐步演化為重要的存儲介質(zhì)，需要做高可用。

本人的看法是，緩存是否高可用，需要根據(jù)實際的場景而定。臨界點是是否對后端的數(shù)據(jù)庫造成影響。

具體的決策依據(jù)需要根據(jù)，集群的規(guī)模（數(shù)據(jù)，緩存），成本（服務器，運維），系統(tǒng)性能（并發(fā)量，吞吐量，響應時間）等方面綜合評價。

8.1解決方法

緩存的高可用，一般通過分布式和復制實現(xiàn)。分布式實現(xiàn)數(shù)據(jù)的海量緩存，復制實現(xiàn)緩存數(shù)據(jù)節(jié)點的高可用。架構(gòu)圖如下：

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

8.2其他方法

（1）復制雙寫：緩存節(jié)點的復制，由異步改為雙寫，只有兩份都寫成功，才算成功。

（2）虛擬層：一致性Hash存在，假如其中一個HASH環(huán)不可用，數(shù)據(jù)會寫入臨近的環(huán)，當HASH可用時，數(shù)據(jù)又寫入正常的HASH環(huán)，會導致數(shù)據(jù)偏移問題。這種情況，可以考慮在HASH環(huán)前面加一個虛擬層實現(xiàn)。

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

方式很多，需要根據(jù)業(yè)務場景靈活選擇。

九、緩存雪崩

雪崩是指當大量緩存失效時，導致大量的請求訪問數(shù)據(jù)庫，導致數(shù)據(jù)庫服務器，無法抗住請求或掛掉的情況。

解決方法：

（1）合理規(guī)劃緩存的失效時間；

（2）合理評估數(shù)據(jù)庫的負載壓力；

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

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

十、緩存穿透

緩存一般是Key，value方式存在，當某一個Key不存在時會查詢數(shù)據(jù)庫，假如這個Key，一直不存在，則會頻繁的請求數(shù)據(jù)庫，對數(shù)據(jù)庫造成訪問壓力。

解決方法：

（1）對結(jié)果為空的數(shù)據(jù)也進行緩存，當此key有數(shù)據(jù)后，清理緩存；

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