分布式应用之分布式缓存
為什么要使用分布式緩存
高并發(fā)環(huán)境下，例如典型的淘寶雙11秒殺，幾分鐘內(nèi)上億的用戶涌入淘寶，這個時候如果訪問不加攔截，讓大量的讀寫請求涌向數(shù)據(jù)庫，由于磁盤的處理速度與內(nèi)存顯然不在一個量級，服務器馬上就要宕機。從減輕數(shù)據(jù)庫的壓力和提高系統(tǒng)響應速度兩個角度來考慮，都會在數(shù)據(jù)庫之前加一層緩存，訪問壓力越大的，在緩存之前就開始CDN攔截圖片等訪問請求。
并且由于最早的單臺機器的內(nèi)存資源以及承載能力有限，如果大量使用本地緩存，也會使相同的數(shù)據(jù)被不同的節(jié)點存儲多份，對內(nèi)存資源造成較大的浪費，因此，才催生出了分布式緩存。
?
分布式緩存應用場景
本文介紹緩存的原理，緩存的分類，緩存的設計，CDN緩存（原理，架構(gòu)參考和技術(shù)實踐），反向代理緩存（原理，Squid架構(gòu)實踐和常用代理緩存之間的比較）等。
目錄
1. 緩存概述
緩存是分布式系統(tǒng)中的重要組件，主要解決高并發(fā)，大數(shù)據(jù)場景下，熱點數(shù)據(jù)訪問的性能問題。提供高性能的數(shù)據(jù)快速訪問。
1.1 緩存原理
1.2 緩存分類
在分布式系統(tǒng)中，緩存的應用非常廣泛，從部署角度有以下幾個方面的緩存應用。
- CDN緩存；
- 反向代理緩存；
- 分布式Cache；
- 本地應用緩存；
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ù)；- 同步機制1. 實時寫入（PUSH）2. 異步刷新（PUSH & PULL）2. CDN緩存
CDN主要解決將數(shù)據(jù)緩存到離用戶最近的位置，一般緩存靜態(tài)資源文件（頁面，腳本，圖片，視頻，文件等）。國內(nèi)網(wǎng)絡異常復雜，跨運營商的網(wǎng)絡訪問會很慢。為了解決跨運營商或各地用戶訪問問題，可以在重要的城市，部署CDN應用。使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡擁塞，提高用戶訪問響應速度和命中率。
2.1 CDN原理
CDN的基本原理是廣泛采用各種緩存服務器，將這些緩存服務器分布到用戶訪問相對集中的地區(qū)或網(wǎng)絡中，在用戶訪問網(wǎng)站時，利用全局負載技術(shù)將用戶的訪問指向距離最近的工作正常的緩存服務器上，由緩存服務器直接響應用戶請求。
未部署CDN應用前應用架構(gòu)
網(wǎng)絡路徑：
- 請求：本機網(wǎng)絡（局域網(wǎng)）--> 運營商網(wǎng)絡 --> 應用服務器機房
- 響應：應用服務器機房 --> 運營商網(wǎng)絡 --> 本機網(wǎng)絡（局域網(wǎng)）
在不考慮復雜網(wǎng)絡的情況下，從請求到響應需要經(jīng)過3個節(jié)點，6個步驟完成一次用戶訪問操作。
網(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)缺點
優(yōu)點
- 本地Cache加速：提升訪問速度，尤其含有大量圖片和靜態(tài)頁面站點；
- 鏡像服務：消除了不同運營商之間互聯(lián)的瓶頸造成的影響，實現(xiàn)了跨運營商的網(wǎng)絡加速，保證不同網(wǎng)絡中的用戶都能得到良好的訪問質(zhì)量；
- 遠程加速：遠程訪問用戶根據(jù)DNS負載均衡技術(shù)智能自動選擇Cache服務器，選擇最快的Cache服務器，加快遠程訪問的速度；
- 帶寬優(yōu)化：自動生成服務器的遠程Mirror（鏡像）cache服務器，遠程用戶訪問時從cache服務器上讀取數(shù)據(jù)，減少遠程訪問的帶寬、分擔網(wǎng)絡流量、減輕原站點WEB服務器負載等功能。
- 集群抗攻擊：廣泛分布的CDN節(jié)點加上節(jié)點之間的智能冗余機制，可以有效地預防黑客入侵以及降低各種D.D.o.S攻擊對網(wǎng)站的影響，同時保證較好的服務質(zhì)量。
缺點
- 動態(tài)資源緩存，需要注意實時性；
解決辦法：主要緩存靜態(tài)資源，動態(tài)資源建立多級緩存或準實時同步等。
- 如何保證數(shù)據(jù)的一致性和實時性需要權(quán)衡考慮。
解決辦法：設置緩存失效時間；數(shù)據(jù)版本號等。
2.3 CDN架構(gòu)參考
CDN架構(gòu)參考
2.4 CDN技術(shù)實踐
目前，中小型互聯(lián)網(wǎng)公司，綜合成本考慮，一般租用第三方CDN服務，大型互聯(lián)網(wǎng)公司，采用自建或第三方結(jié)合的方式。比如淘寶剛開始使用第三方的，當流量很大后，第三方公司無法支撐其CDN流量，淘寶最后采用自建CDN的方式實現(xiàn)。
例如淘寶的CDN架構(gòu)，如下圖所示：
淘寶CDN架構(gòu)
3. 反向代理緩存
反向代理是指在網(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
image
Squid 反向代理加速網(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)簡單的緩存。4. 分布式緩存
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)要素。常用的中間件有Memcached、Redis。
4.1 Memcached緩存
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服務器上可進行存取操作，簡單，方便多種緩存參考此協(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.1 Memcached原理
Memcached工作流程
MemCached的工作流程如下：
?
（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.2 Memcached集群
Memcached 雖然稱為 “ 分布式 ” 緩存服務器，但服務器端并沒有 “ 分布式 ” 功能。每個服務器都是完全獨立和隔離的服務。 memcached 的分布式，是由客戶端程序?qū)崿F(xiàn)的。
當向Memcached集群存入/取出key value時，memcached客戶端程序根據(jù)一定的算法計算存入哪臺服務器，然后再把key value值存到此服務器中。
因此，存取數(shù)據(jù)分二步走：
第一步，選擇服務器；
第二步，存取數(shù)據(jù)。
Memcached存取數(shù)據(jù)
分布式算法
選擇服務器算法有兩種，一種是根據(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.2 Redis緩存
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.1 Redis常用數(shù)據(jù)類型
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。
Hash類型
- 常用命令：hget,hset,hgetall
-
應用場景：以存儲一個用戶信息對象數(shù)據(jù)為例：
?image
- 實現(xiàn)方式：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。
List類型
- 常用命令：lpush,rpush,lpop,rpop,lrange
- 應用場景：List類型的應用場景非常多，也是Redis最重要的數(shù)據(jù)結(jié)構(gòu)之一，比如twitter的關(guān)注列表，粉絲列表等都可以用Redis的list結(jié)構(gòu)來實現(xiàn)。
- 實現(xiàn)方式：List的實現(xiàn)為一個雙向鏈表，可以支持反向查找和遍歷，方便操作。不過帶來了部分額外的內(nèi)存開銷，Redis內(nèi)部的很多實現(xiàn)，包括發(fā)送緩沖隊列等也都是用的這個數(shù)據(jù)結(jié)構(gòu)。
Set類型
- 常用命令：sadd,spop,smembers,sunion
- 應用場景：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)的原因。
Sorted Set類型
- 常用命令：zadd,zrange,zrem,zcard；
- 使用場景：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)方式：Sorted set的內(nèi)部使用HashMap和跳躍表(SkipList)來保證數(shù)據(jù)的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表里存放的 是所有的成員，排序依據(jù)是HashMap里存的score,使用跳躍表的結(jié)構(gòu)可以獲得比較高的查找效率，并且在實現(xiàn)上比較簡單。
4.2.2 Redis集群
通過KeepAlived實現(xiàn)的高可用方案
?
- 切換流程：1. 當Master掛了后，VIP漂移到Slave；Slave 上keepalived 通知redis 執(zhí)行：slave of no one, 開始提供業(yè)務2. 當Master起來后，VIP 地址不變，Master的keepalived通知redis執(zhí)行slave of slave IP host，開始作為從同步數(shù)據(jù)3. 依次類推- 主從同時宕機情況：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文件（避免重啟加載慢）Twemproxy由Twitter公司開源的c版本proxy，同時支持memcached和redis，Twitter用它主要減少前端與緩存服務間網(wǎng)絡連接數(shù)。
- Twemproxy方案的特點：快速、輕量級、減少后端Cache Server連接數(shù)、易配置、支持ketama、modula、random、常用hash分片算法等。
Twemproxy集群方案
注：圖中使用Keepalived實現(xiàn)高可用主備方案，解決proxy單點問題。
-
Twemproxy方案的優(yōu)點：
- 對于客戶端而言，redis集群是透明的，客戶端簡單，遍于動態(tài)擴容
- Proxy為單點、處理一致性hash時，集群節(jié)點可用性檢測不存在腦裂問題
- 高性能，CPU密集型，而redis節(jié)點集群多CPU資源冗余，可部署在redis節(jié)點集群上，不需要額外設備
4.3 Memcached與Redis的比較
- 數(shù)據(jù)結(jié)構(gòu)：Memcache只支持key value存儲方式，Redis支持更多的數(shù)據(jù)類型，比如Key value，hash，list，set，zset；
- 多線程：Memcache支持多線程，redis支持單線程；CPU利用方面Memcache優(yōu)于redis；
- 持久化：Memcache不支持持久化，Redis支持持久化；
- 內(nèi)存利用率：memcache高，redis低（采用壓縮的情況下比memcache高）；
- 過期策略：memcache過期后，不刪除緩存，會導致下次取數(shù)據(jù)數(shù)據(jù)的問題，Redis有專門線程，清除緩存數(shù)據(jù)。
5. 本地緩存
本地緩存是指應用內(nèi)部的緩存，標準的分布式系統(tǒng)，一般有多級緩存構(gòu)成。本地緩存是離應用最近的緩存，一般可以將數(shù)據(jù)緩存到硬盤或內(nèi)存。
- 硬盤緩存
將數(shù)據(jù)緩存到硬盤到，讀取時從硬盤讀取。原理是直接讀取本機文件，減少了網(wǎng)絡傳輸消耗，比通過網(wǎng)絡讀取數(shù)據(jù)庫速度更快?？梢詰迷趯λ俣纫蟛皇呛芨?#xff0c;但需要大量緩存存儲的場景。
- 內(nèi)存緩存
直接將數(shù)據(jù)存儲到本機內(nèi)存中，通過程序直接維護緩存對象，是訪問速度最快的方式。
6. 緩存架構(gòu)示例
緩存架構(gòu)示例
職責劃分：
- CDN：存放HTML,CSS,JS等靜態(tài)資源；
- 反向代理：動靜分離，只緩存用戶請求的靜態(tài)資源；
- 分布式緩存：緩存數(shù)據(jù)庫中的熱點數(shù)據(jù)；
- 本地緩存：緩存應用字典等常用數(shù)據(jù)；
請求過程：
- 瀏覽器向客戶端發(fā)起請求，如果CDN有緩存則直接返回；
- 如果CDN無緩存，則訪問反向代理服務器；
- 如果反向代理服務器有緩存則直接返回；
- 如果反向代理服務器無緩存或動態(tài)請求，則訪問應用服務器；
- 應用服務器訪問本地緩存；如果有緩存，則返回代理服務器，并緩存數(shù)據(jù)；（動態(tài)請求不緩存）
- 如果本地緩存無數(shù)據(jù)，則讀取分布式緩存；并返回應用服務器；應用服務器將數(shù)據(jù)緩存到本地緩存（部分）；
- 如果分布式緩存無數(shù)據(jù)，則應用程序讀取數(shù)據(jù)庫數(shù)據(jù)，并放入分布式緩存。??
?
分布式緩存的常見問題和挑戰(zhàn)
1.緩存雪崩
緩存雪崩我們可以簡單的理解為：由于原有緩存失效，新緩存未到期間(例如：我們設置緩存時采用了相同的過期時間，在同一時刻出現(xiàn)大面積的緩存過期)，所有原本應該訪問緩存的請求都去查詢數(shù)據(jù)庫了，而對數(shù)據(jù)庫CPU和內(nèi)存造成巨大壓力，嚴重的會造成數(shù)據(jù)庫宕機。從而形成一系列連鎖反應，造成整個系統(tǒng)崩潰。
2.緩存穿透
緩存穿透是指用戶查詢數(shù)據(jù)，在數(shù)據(jù)庫沒有，自然在緩存中也不會有。這樣就導致用戶查詢的時候，在緩存中找不到，每次都要去數(shù)據(jù)庫再查詢一遍，然后返回空（相當于進行了兩次無用的查詢）。這樣請求就繞過緩存直接查數(shù)據(jù)庫，這也是經(jīng)常提的緩存***率問題。
3.緩存預熱
緩存預熱這個應該是一個比較常見的概念，相信很多小伙伴都應該可以很容易的理解，緩存預熱就是系統(tǒng)上線后，將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。這樣就可以避免在用戶請求的時候，先查詢數(shù)據(jù)庫，然后再將數(shù)據(jù)緩存的問題！用戶直接查詢事先被預熱的緩存數(shù)據(jù)！
4.緩存更新
除了緩存服務器自帶的緩存失效策略之外，我們還可以根據(jù)具體的業(yè)務需求進行自定義的緩存淘汰，常見的策略有兩種：
（1）定時去清理過期的緩存；
（2）當有用戶請求過來時，再判斷這個請求所用到的緩存是否過期，過期的話就去底層系統(tǒng)得到新數(shù)據(jù)并更新緩存。
兩者各有優(yōu)劣，***種的缺點是維護大量緩存的key是比較麻煩的，第二種的缺點就是每次用戶請求過來都要判斷緩存失效，邏輯相對比較復雜！具體用哪種方案，大家可以根據(jù)自己的應用場景來權(quán)衡。
5.緩存降級
當訪問量劇增、服務出現(xiàn)問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。系統(tǒng)可以根據(jù)一些關(guān)鍵數(shù)據(jù)進行自動降級，也可以配置開關(guān)實現(xiàn)人工降級。
降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結(jié)算）。
在進行降級之前要對系統(tǒng)進行梳理，看看系統(tǒng)是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日志級別設置預案：
（1）一般：比如有些服務偶爾因為網(wǎng)絡抖動或者服務正在上線而超時，可以自動降級；
（2）警告：有些服務在一段時間內(nèi)成功率有波動（如在95~100%之間），可以自動降級或人工降級，并發(fā)送告警；
（3）錯誤：比如可用率低于90%，或者數(shù)據(jù)庫連接池被打爆了，或者訪問量突然猛增到系統(tǒng)能承受的***閥值，此時可以根據(jù)情況自動降級或者人工降級；
（4）嚴重錯誤：比如因為特殊原因數(shù)據(jù)錯誤了，此時需要緊急人工降級。
總結(jié)
以上是生活随笔為你收集整理的分布式应用之分布式缓存的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： vmware虚拟机centos7扩容
- 下一篇： Delphi的常用函数