一、概述
主要功能：應用解耦，異步消息，流量削鋒等問題
架構設計：實現高性能，高可用，可伸縮和最終一致性架構
常用消息隊列：ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ
使用場景：
1）RabbitMQ：對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次（集群不能動態擴展）
2）RocketMQ：具有高吞吐量、高可用性、適合大規模分布式系統應用的特點（支持的語言較少，語言支持的情況下優先選擇）
3）Kafka：基於Pull的模式來處理消息消費，追求高吞吐量，適合產生大量數據的互聯網服務的數據收集業務（多數用於處理日志）
二、核心功能理解
解耦：一個事務，只關心核心的流程。而需要依賴其他系統但不那么重要的事情，有通知即可，無需等待結果
異步消息：
一致性：保證消息的可靠性
1）強一致性：
2）最終一致性：主要是用“記錄”和“補償”的方式。在做所有的不確定的事情之前，先把事情記錄下來，然后去做不確定的事情，結果可能是：成功、失敗或是不確定，“不確定”（例如超時等）可以等價為失敗。成功就可以把記錄的東西清理掉了，對於失敗和不確定，可以依靠定時任務等方式把所有失敗的事情重新執行一遍，直到成功為止
三、使用總結
1.消息隊列不是萬能的，對於需要強事務保證而且延遲敏感的，RPC是優於消息隊列的。
2.對於一些無關痛癢，或者對於別人非常重要但是對於自己不是那么關心的事情，可以利用消息隊列去做。
3.支持最終一致性的消息隊列，能夠用來處理延遲不那么敏感的“分布式事務”場景，而且相對於笨重的分布式事務，可能是更優的處理方式。
4.當上下游系統處理能力存在差距的時候，利用消息隊列做一個通用的“漏斗”，在下游有能力處理的時候，再進行分發。
一、概述
原理：
1） 將數據寫入/讀取速度更快的存儲（設備）
2） 將數據緩存到離應用最近的位置
3）將數據緩存到離用戶最近的位置
緩存分類
1）CDN緩存
2）反向代理緩存
3）分布式Cache
4）本地應用緩存
緩存媒介
1）常用中間件：Varnish，Ngnix，Squid，Memcache，Redis，Ehcache等
2）緩存的內容：文件，數據，對象
3）緩存的介質：CPU，內存（本地，分布式），磁盤（本地，分布式）
緩存設計
1）緩存的內容：1.熱點數據；2.靜態資源
2）緩存的位置：CDN，反向代理，分布式緩存服務器，本機（內存，硬盤）
緩存策略
1）過期策略：（1）固定時間：比如指定緩存的時間是30分鍾；（2）相對時間：比如最近10分鍾內沒有訪問的數據；
2）同步機制：（1）實時寫入；（2）異步刷新
緩存的目的：將熱點數據放到離用戶最近或訪問速度更快的介質中，加快數據的訪問，減小響應時間
二、CDN緩存
原理：CDN的基本原理是廣泛采用各種緩存服務器，將緩存服務器分布到用戶訪問相對集中的地區或網絡中，在用戶訪問網站時，利用全局負載技術將用戶的訪問指向距離最近的工作正常的緩存服務器上，由緩存服務器直接響應用戶請求
CDN主要解決將數據緩存到離用戶最近的位置，一般緩存靜態資源文件（頁面，腳本，圖片，視頻，文件等）。
國內網絡異常復雜，跨運營商的網絡訪問會很慢。為了解決跨運營商或各地用戶訪問問題，可以在重要的城市，部署CDN應用。使用戶就近獲取所需內容，降低網絡擁塞，提高用戶訪問響應速度和命中率。
（1） 未部署CDN應用前
網絡請求路徑：
請求：本機網絡（局域網）——》運營商網絡——》應用服務器機房
響應：應用服務器機房——》運營商網絡——》本機網絡（局域網）
在不考慮復雜網絡的情況下，從請求到響應需要經過3個節點，4個步驟完成一次用戶訪問操作。
（2） 部署CDN應用后
網絡路徑：
請求：本機網絡（局域網）——》運營商網絡
響應：運營商網絡——》本機網絡（局域網）
在不考慮復雜網絡的情況下，從請求到響應需要經過2個節點，2個步驟完成一次用戶訪問操作。
與不部署CDN服務相比，減少了1個節點，2個步驟的訪問。極大的提高的系統的響應速度。
優點
1）本地Cache加速：提升訪問速度，尤其含有大量圖片和靜態頁面站點
2）鏡像服務：消除了不同運營商之間互聯的瓶頸造成的影響，實現了跨運營商的網絡加速，保證不同網絡中的用戶都能得到良好的訪問質量
3）遠程加速：遠程訪問用戶根據DNS負載均衡技術智能自動選擇Cache服務器，選擇最快的Cache服務器，加快遠程訪問的速度
4）帶寬優化：自動生成服務器的遠程Mirror（鏡像）cache服務器，遠程用戶訪問時從cache服務器上讀取數據，減少遠程訪問的帶寬、分擔網絡流量、減輕原站點WEB服務器負載等功能
5）集群抗攻擊：廣泛分布的CDN節點加上節點之間的智能冗余機制，可以有效地預防黑客入侵以及降低各種D.D.o.S攻擊對網站的影響，同時保證較好的服務質量
缺點
1）動態資源緩存，需要注意實時性（解決方法：主要緩存靜態資源，動態資源建立多級緩存或准實時同步）
2）.如何保證數據的一致性和實時性需要權衡考慮（解決方法：設置緩存失效時間（1個小時，最終一致性））
CND技術實踐
目前，中小型互聯網公司，綜合成本考慮，一般租用第三方CDN服務，大型互聯網公司，采用自建或第三方結合的方式。比如淘寶剛開始使用第三方的，當流量很大后，第三方公司無法支撐其CDN流量，淘寶最后采用自建CDN的方式實現。
淘寶CDN，如下圖（來自網絡）：
三、反向代理緩存
原理：反向代理位於應用服務器機房，處理所有對WEB服務器的請求。如果用戶請求的頁面在代理服務器上有緩沖的話，代理服務器直接將緩沖內容發送給用戶。如果沒有緩沖則先向WEB服務器發出請求，取回數據，本地緩存后再發送給用戶。通過降低向WEB服務器的請求數，從而降低了WEB服務器的負載
代理緩存對比：常用的代理緩存有Varnish，Squid，Ngnix
1）varnish和squid是專業的cache服務，nginx需要第三方模塊支持；
2）Varnish采用內存型緩存，避免了頻繁在內存、磁盤中交換文件，性能比Squid高；
3）Varnish由於是內存cache，所以對小文件如css,js,小圖片啥的支持很棒，后端的持久化緩存可以采用的是Squid或ATS
4） Squid功能全而大，適合於各種靜態的文件緩存，一般會在前端掛一個HAProxy或nginx做負載均衡跑多個實例
5） Nginx采用第三方模塊ncache做的緩沖，性能基本達到varnish，一般作為反向代理使用，可以實現簡單的緩存
反向代理一般緩存靜態資源，動態資源轉發到應用服務器處理
Squid示例
Squid 反向代理一般只緩存靜態資源，動態程序默認不緩存。根據從 WEB 服務器返回的 HTTP 頭標記來緩沖靜態頁面。有四個最重要 HTTP 頭標記：
Last-Modified: 告訴反向代理頁面什么時間被修改
Expires: 告訴反向代理頁面什么時間應該從緩沖區中刪除
Cache-Control: 告訴反向代理頁面是否應該被緩沖
Pragma: 用來包含實現特定的指令，最常用的是 Pragma:no-cache
Squid 反向代理加速網站實例
（1） 通過DNS的輪詢技術，將客戶端的請求分發給其中一台 Squid 反向代理服務器處理；
（2） 如果這台 Squid 緩存了用戶的請求資源，則將請求的資源直接返回給用戶；
（3） 否則這台 Squid 將沒有緩存的請求根據配置的規則發送給鄰居 Squid 和后台的 WEB 服務器處理；
（4） 這樣既減輕后台 WEB 服務器的負載，又提高整個網站的性能和安全性。
四、分布式緩存-memecache
CDN,反向代理緩存，主要解決靜態文件，或用戶請求資源的緩存，數據源一般為靜態文件或動態生成的文件（有緩存頭標識）。
分布式緩存，主要指緩存用戶經常訪問數據的緩存，數據源為數據庫。一般起到熱點數據訪問和減輕數據庫壓力的作用。
目前分布式緩存設計，在大型網站架構中是必備的架構要素。常用的中間件有Memcache，Redis。
Memcache是一個高性能，分布式內存對象緩存系統，通過在內存里維護一個統一的巨大的hash表，它能夠用來存儲各種格式的數據，包括圖像、視頻、文件以及數據庫檢索的結果等。簡單的說就是將數據調用到內存中，然后從內存中讀取，從而大大提高讀取速度。
特性：
1）使用物理內存作為緩存區，可獨立運行在服務器上。每個進程最大2G，如果想緩存更多的數據，可以開辟更多的memcache進程（不同端口）或者使用分布式memcache進行緩存，將數據緩存到不同的物理機或者虛擬機上
2）使用key-value的方式來存儲數據，這是一種單索引的結構化數據組織形式，可使數據項查詢時間復雜度為O(1)
3）協議簡單：基於文本行的協議，直接通過telnet在memcached服務器上可進行存取數據操作，簡單，方便
4）內置的內存管理方式：所有數據都保存在內存中，存取數據比硬盤快，當內存滿后，通過LRU算法自動刪除不使用的緩存，但沒有考慮數據的容災問題，重啟服務，所有數據會丟失
5）分布式：各個memcached服務器之間互不通信，各自獨立存取數據，不共享任何信息。服務器並不具有分布式功能，分布式部署取決於memcache客戶端
6）緩存策略：Memcached的緩存策略是LRU（最近最少使用）到期失效策略。在memcached內存儲數據項時，可以指定它在緩存的失效時間，默認為永久。當memcached服務器用完分配的內時，失效的數據被首先替換，然后也是最近未使用的數據。在LRU中，memcached使用的是一種Lazy Expiration策略，自己不會監控存入的key/vlue對是否過期，而是在獲取key值時查看記錄的時間戳，檢查key/value對空間是否過期，這樣可減輕服務器的負載
1、MemCached介紹
MemCached是一種基於內存的key-value存儲，用來存儲小塊的任意數據（字符串、對象）。它便於快速開發，減輕開發難度，解決了大數據量緩存的很多問題，本質上，它是一個簡潔的key-value存儲系統
2、MemCached工作原理
主要通過緩存數據庫查詢結果，減少數據庫訪問次數，以提高動態Web應用的速度。
工作流程
1）先檢查客戶端的請求數據是否在memcached中，如有，直接把請求數據返回，不再對數據庫進行任何操作
2）如果請求的數據不在memcached中，就去查數據庫，把從數據庫中獲取的數據返回給客戶端，同時把數據緩存一份到memcached中（memcached客戶端不負責，需要程序實現）
3）每次更新數據庫的同時更新memcached中的數據，保證一致性
4）當分配給memcached內存空間用完之后，會使用LRU（Least Recently Used，最近最少使用）策略加上到期失效策略，失效數據首先被替換，然后再替換掉最近未使用的數據
Memcache集群
memcached 雖然稱為 “ 分布式 ” 緩存服務器，但服務器端並沒有 “ 分布式 ” 功能。每個服務器都是完全獨立和隔離的服務。 memcached 的分布式，是由客戶端程序實現的。
當向memcached集群存入/取出key value時，memcached客戶端程序根據一定的算法計算存入哪台服務器，然后再把key value值存到此服務器中。
存取數據分二步走，第一步，選擇服務器，第二步存取數據。
選擇服務器算法有兩種，一種是根據余數來計算分布，另一種是根據散列算法來計算分布。
1）余數算法：先求得鍵的整數散列值，再除以服務器台數，根據余數確定存取服務器
（優點：計算簡單，高效；缺點：在memcached服務器增加或減少時，幾乎所有的緩存都會失效，危險：所有壓力直接抵達后端，數據庫會崩潰的）
2）散列算法：先算出memcached服務器的散列值，並將其分布到0到2的32次方的圓上，然后用同樣的方法算出存儲數據的鍵的散列值並映射至圓上，最后從數據映射到的位置開始順時針查找，將數據保存到查找到的第一個服務器上，如果超過2的32次方，依然找不到服務器，就將數據保存到第一台memcached服務器上（添加了一台memcached服務器，只在圓上增加服務器的逆時針方向的第一台服務器上的鍵會受到影響）
一致性Hash算法：解決了余數算法增加節點命中大幅額度降低的問題，理論上，插入一個實體節點，平均會影響到：虛擬節點數 /2 的節點數據的命中。
五、分布式緩存-redis
簡介：
1）Redis 是一個開源（BSD許可）的，基於內存的，多數據結構存儲系統。可以用作數據庫、緩存和消息中間件
2）支持多種類型的數據結構，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 與范圍查詢， bitmaps， hyperloglogs 和 地理空間（geospatial） 索引半徑查詢
3）內置了 復制（replication），LUA腳本（Lua scripting）， LRU驅動事件（LRU eviction），事務（transactions） 和不同級別的 磁盤持久化（persistence）， 並通過 Redis哨兵（Sentinel）和自動分區（Cluster）提供高可用性（high availability）
Redis緩存策略
（1）緩存【失效】：客戶端請求數據先從緩存中查詢，如果沒有再查詢數據庫，最后將數據放入緩存
（2）緩存【命中】：客戶端從緩存中直接取到數據，返回結果
（3）緩存【更新】：客戶端寫入數據到數據庫，成功之后，讓緩存失效（下次請求時從緩存中拿不到，則查詢數據庫，再放入緩存）
Redis常用數據類型
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,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。
Redis集群
（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節點集群上，不需要額外設備
哨兵模式：
1）哨兵(sentinel) 會不斷地檢查Master和Slave是否運作正常
2）當被監控的某個Redis節點出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。
3）自動故障遷移(Automatic failover)：當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作，它會將失效Master的其中一個Slave升級為新的Master, 並讓失效Master的其他Slave改為復制新的Master；當客戶端試圖連接失效的Master時，集群也會向客戶端返回新Master的地址，使得集群可以使用現在的Master替換失效Master。
4）Master和Slave服務器切換后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的內容都會發生相應的改變，即，Master主服務器的redis.conf配置文件中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換
5）優點：系統更健壯，可用性更高
6）缺點：Redis較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜。為避免這一問題，運維人員在系統上線時必須確保有足夠的空間，這對資源造成了很大的浪費；配置復雜
Cluster集群模式
1）架構模式：支撐N個redis master node，每個master node都可以掛載多個slave node（讀寫分離：寫到master，然后讀就從mater對應的slave去讀）
2）使用場景：redis cluster，主要是針對海量數據+高並發+高可用的場景，海量數據，如果你的數據量很大，那么建議就用redis cluster
3）hash slot算法：
（1）redis cluster有固定的16384個hash slot，對每個key計算CRC16值，然后對16384取模，可以獲取key對應的hash slot
（2）redis cluster中每個master都會持有部分slot，比如有3個master，那么可能每個master持有5000多個hash slot
（3）hash slot讓node的增加和移除很簡單，增加一個master，就將其他master的hash slot移動部分過去，減少一個master，就將它的hash slot移動到其他master上去（移動hash slot的成本是非常低的）
（4）客戶端的api，可以對指定的數據，讓他們走同一個hash slot，通過hash tag來實現
4）通信機制
（1）gossip：好處在於，元數據的更新比較分散，不是集中在一個地方，更新請求會陸陸續續，打到所有節點上去更新，有一定的延時，降低了壓力; 缺點，元數據更新有延時，可能導致集群的一些操作會有一些滯后
（2）每個節點都有一個專門用於節點間通信的端口，就是自己提供服務的端口號+10000，比如7001，那么用於節點間通信的就是17001端口（每個節點每隔一段時間都會往另外幾個節點發送ping消息，同時其他幾點接收到ping之后返回pong）
5）gossip協議：包含多種消息，包括ping，pong，meet，fail，等等
（1）meet: 某個節點發送meet給新加入的節點，讓新節點加入集群中，然后新節點就會開始與其他節點進行通信
（2）ping: 每個節點都會頻繁給其他節點發送ping，其中包含自己的狀態還有自己維護的集群元數據，互相通過ping交換元數據
（3）pong: 返回ping和meet，包含自己的狀態和其他信息，也可以用於信息廣播和更新
（4）fail: 某個節點判斷另一個節點fail之后，就發送fail給其他節點，通知其他節點，指定的節點宕機了
6）高可用
（1）如果一個節點認為某個節點pfail了，那么會在gossip ping消息中，ping給其他節點，如果超過半數的節點都認為pfail了，那么就會變成fail
（2）對宕機的master node，從其所有的slave node中，選擇一個切換成master node（檢查每個slave node與master node斷開連接的時間，如果超過了cluster-node-timeout * cluster-slave-validity-factor，那么就沒有資格切換成master）
（3）每個從節點，都根據自己對master復制數據的offset，來設置一個選舉時間，offset越大（復制數據越多）的從節點，選舉時間越靠前，優先進行選舉
（4）所有的master node開始slave選舉投票，給要進行選舉的slave進行投票，如果大部分master node（N/2 + 1）都投票給了某個從節點，那么選舉通過，那個從節點可以切換成master
（5）從節點執行主備切換，從節點切換為主節點
六、memcache與redis對比
數據結構：Memcache只支持key value存儲方式，Redis支持更多的數據類型，比如Key value，hash，list，set，zset
多線程：Memcache支持多線程，redis支持單線程；CPU利用方面Memcache優於redis
持久化：Memcache不支持持久化，Redis支持持久化
內存利用率：memcache高，redis低（采用壓縮的情況下比memcache高）
過期策略：memcache過期后，不刪除緩存，會導致下次取數據數據的問題，Redis有專門線程，清除緩存數據
6、Redis與MemCached的區別
（1）Redis和Memcache都是將數據存放在內存中，都是內存數據庫。不過memcache還可用於緩存其他東西，例如圖片、視頻等等；
（2）Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲；
（3）虛擬內存–Redis當物理內存用完時，可以將一些很久沒用到的value 交換到磁盤；
（4）分布式集群部署：
a、memcache集群節點間的數據是獨立的，不能相互通訊，但可以利用magent開源軟件解決 ;
b、Redis高可用的，可以做一主多從，主從之間進行數據同步。 當Master宕機后，通過選舉算法(Paxos、Raft)從slave中選舉出新Master繼續對外提供服務，
主機恢復后以slave的身份重新加入
（5）存儲數據安全–memcache掛掉后，數據沒了；redis可以定期保存到磁盤（持久化）；
（6）災難恢復–memcache掛掉后，數據不可恢復; redis數據丟失后可以通過aof恢復；
Redis簡介
Redis 是完全開源免費的，是一個高性能的key-value數據庫。
Redis 與其他 key - value 緩存產品有以下三個特點：
（1）Redis支持數據的持久化，可以將內存中的數據保存在磁盤中，重啟的時候可以再次加載進行使用。
（2）Redis支持String、list、set、zset、hash等數據結構的存儲。
（3）Redis支持數據的備份，即master-slave模式的數據備份。
七、本地緩存
硬盤緩存：將數據緩存到硬盤到，讀取時從硬盤讀取。原理是直接讀取本機文件，減少了網絡傳輸消耗，比通過網絡讀取數據庫速度更快。可以應用在對速度要求不是很高，但需要大量緩存存儲的場景
內存緩存：直接將數據存儲到本機內存中，通過程序直接維護緩存對象，是訪問速度最快的方式（適合少量緩存，對速度敏感的場景）
八、緩存架構示例
職責划分（建議使用方式，非絕得）：
1）CDN：存放HTML,CSS,JS等靜態資源；
2）反向代理：動靜分離，只緩存用戶請求的靜態資源
3）分布式緩存：緩存數據庫中的熱點數據
4）本地緩存：緩存應用字典等常用數據
請求過程
1）瀏覽器向客戶端發起請求，如果CDN有緩存則直接返回
2） 如果CDN無緩存，則訪問反向代理服務器；如果反向代理服務器有緩存則直接返回
3）如果反向代理服務器無緩存或動態請求，則訪問應用服務器
4）應用服務器訪問本地緩存；如果有緩存，則返回代理服務器，並緩存數據；（動態請求不緩存）
5）如果本地緩存無數據，則讀取分布式緩存；並返回應用服務器；應用服務器將數據緩存到本地緩存（部分）
6） 如果分布式緩存無數據，則應用程序讀取數據庫數據，並放入分布式緩存
九、數據一致性（緩存屬於持久化數據的一個副本，因此不可避免的會出現數據不一致問題）
有問題的幾種更新緩存策略
（1）先更新緩存，然后更新DB。見下圖：
從圖中可以看出，兩個並發寫操作，由於某些原因（io阻塞，cpu時間片分配，協程調度，網絡原因等等），導致Thread2的更新DB晚於Thread1的更新DB，但是Redis中此時的數據Thread1的，而DB中的數據時Thread2的，這就出現了不一致的問題，DB中是臟數據
（2）先更新DB，然后更新緩存。見下圖：
從圖中可以看出，兩個並發寫操作，由於某些原因導致Thread2的更新Redis晚於Thread1的更新Redis ，但是DB中此時的數據Thread1的，而Redis中的數據時Thread2的，這就出現了不一致的問題
（3）先刪除緩存，然后再更新數據庫。見下圖：
兩個並發操作，一個是更新操作，另一個是查詢操作，更新操作刪除緩存后，查詢操作沒有命中緩存，會把老數據讀出來后放到緩存中，然后更新操作更新了DB。於是，在緩存中的數據還是老的數據，導致緩存中的數據是臟的
（4）先數據庫，成功之后，讓緩存失效，下次請求時從緩存中拿不到，則查詢數據庫，再放入緩存。見下圖：
這種更新策略是我們實際最常用的，但也可能出現問題。實際上出現問題的概率可能非常低，因為這個條件需要發生在讀緩存時緩存失效，而且並發着有一個寫操作。
而實際上數據庫的寫操作會比讀操作慢得多，而且還要鎖表，而讀操作必需在寫操作前進入數據庫操作，而又要晚於寫操作更新緩存，所有的這些條件都具備的概率基本並不大。
使用場景
1）先寫緩存，再寫數據庫：假如緩存寫成功，但寫數據庫失敗或響應延遲，則下次讀取（並發讀）緩存時，就出現臟讀（不建議此種使用方式）
假如緩存寫成功，但寫數據庫失敗或響應延遲，則下次讀取（並發讀）緩存時，就出現臟讀；
2）先寫數據庫，再寫緩存：
假如寫數據庫成功，但寫緩存失敗，則下次讀取（並發讀）緩存時，則讀不到數據
（假如讀緩存失敗，先讀數據庫，再回寫緩存的方式實現）
3）緩存異步刷新：需要考慮數據寫入和緩存刷新的時效性（根據經驗值確定合理的數據不一致時間，用戶數據刷新的時間間隔）
指數據庫操作和寫緩存不在一個操作步驟中，比如在分布式場景下，無法做到同時寫緩存或需要異步刷新（補救措施）時候。
第一個場景：
這個寫緩存的方式，本身就是錯誤的，需要改為先寫持久化介質，再寫緩存的方式。
第二個場景：
（1）根據寫入緩存的響應來進行判斷，如果緩存寫入失敗，則回滾數據庫操作；此種方法增加了程序的復雜度，不建議采用；
（2）緩存使用時，假如讀緩存失敗，先讀數據庫，再回寫緩存的方式實現。
第三個場景：
（1）首先確定，哪些數據適合此類場景；
（2）根據經驗值確定合理的數據不一致時間，用戶數據刷新的時間間隔；
其他優化方式：
1）超時：設置合理的超時時間；
2）刷新：定時刷新一定范圍內（根據時間，版本號）的數據；
多級緩存需要考慮的問題
1）緩存與數據庫之間的一致性；
2）多級緩存之前的一致性；
3）緩存副本之前的一致性。
緩存高可用
業界有兩種理論，第一套緩存就是緩存，臨時存儲數據的，不需要高可用。第二種緩存逐步演化為重要的存儲介質，需要做高可用。
緩存的高可用，一般通過分布式和復制實現。分布式實現數據的海量緩存，復制實現緩存數據節點的高可用。架構圖如下：
其中，分布式采用一致性Hash算法，復制采用異步復制。
其他方法
（1）復制雙寫：緩存節點的復制，由異步改為雙寫，只有兩份都寫成功，才算成功。
（2）虛擬層：一致性Hash存在，假如其中一個HASH環不可用，數據會寫入臨近的環，當HASH可用時，數據又寫入正常的HASH環，會導致數據偏移問題。這種情況，可以考慮在HASH環前面加一個虛擬層實現。
（3）多級緩存：比如一級使用本地緩存，二級采用分布式Cahce，三級采用分布式Cache+本地持久化；
十、緩存雪崩：雪崩是指當大量緩存失效時，導致大量的請求訪問數據庫，導致數據庫服務器，無法抗住請求或掛掉的情況
合理規划緩存的失效時間；
合理評估數據庫的負載壓力；
對數據庫進行過載保護或應用層限流
多級緩存設計，緩存高可用
十一、緩存穿透
現象：緩存一般是Key，value方式存在，當某一個Key不存在時會查詢數據庫，假如這個Key，一直不存在，則會頻繁的請求數據庫，對數據庫造成訪問壓力
解決方法：
1）對結果為空的數據也進行緩存，當此key有數據后，清理緩存
2）一定不存在的key，采用布隆過濾器，建立一個大的Bitmap中，查詢時通過該bitmap過濾