前言
緩存技術存在于應用場景的方方面面。從浏覽器請求，到反向代理伺服器，從程序内緩存到分布式緩存。其中緩存政策，算法也是層出不窮，今天就帶大家走進緩存。緩存對于每個開發者來說是相當熟悉了，為了提高程式的性能我們會去加緩存，但是在什麼地方加緩存，如何加緩存呢？
假設一個網站，需要提高性能，緩存可以放在浏覽器，可以放在反向代理伺服器，還可以放在應用程式程序内，同時可以放在分布式緩存系統中。
從使用者請求資料到資料傳回，資料經過了浏覽器，CDN，代理伺服器，應用伺服器，以及資料庫各個環節。每個環節都可以運用緩存技術。
從浏覽器/用戶端開始請求資料，通過 HTTP 配合 CDN 擷取資料的變更情況，到達代理伺服器（Nginx）可以通過反向代理擷取靜态資源。
再往下來到應用伺服器可以通過程序内（堆内）緩存，分布式緩存等遞進的方式擷取資料。如果以上所有緩存都沒有命中資料，才會回源到資料庫。
緩存的請求順序是：使用者請求 → HTTP 緩存 → CDN 緩存 → 代理伺服器緩存 → 程序内緩存 → 分布式緩存 → 資料庫。
看來該技術的架構每個環節都可以加入緩存，看看每個環節是如何應用緩存技術的。
1. HTTP緩存
當使用者通過浏覽器請求伺服器的時候，會發起 HTTP 請求，如果對每次 HTTP 請求進行緩存，那麼可以減少應用伺服器的壓力。
當第一次請求的時候，浏覽器本地緩存庫沒有緩存資料，會從伺服器取資料，并且放到浏覽器的緩存庫中，下次再進行請求的時候會根據緩存的政策來讀取本地或者服務的資訊。
一般資訊的傳遞通過 HTTP 請求頭 Header 來傳遞。目前比較常見的緩存方式有兩種，分别是：
強制緩存
對比緩存
1.1. 強制緩存
當浏覽器本地緩存庫儲存了緩存資訊，在緩存資料未失效的情況下，可以直接使用緩存資料。否則就需要重新擷取資料。
這種緩存機制看上去比較直接，那麼如何判斷緩存資料是否失效呢？這裡需要關注 HTTP Header 中的兩個字段 Expires 和 Cache-Control。
Expires 為服務端傳回的過期時間，用戶端第一次請求伺服器，伺服器會傳回資源的過期時間。如果用戶端再次請求伺服器，會把請求時間與過期時間做比較。
如果請求時間小于過期時間，那麼說明緩存沒有過期，則可以直接使用本地緩存庫的資訊。
反之，說明資料已經過期，必須從伺服器重新擷取資訊，擷取完畢又會更新最新的過期時間。
這種方式在 HTTP 1.0 用的比較多，到了 HTTP 1.1 會使用 Cache-Control 替代。
Cache-Control 中有個 max-age 屬性，機關是秒，用來表示緩存内容在用戶端的過期時間。
例如：max-age 是 60 秒，目前緩存沒有資料，用戶端第一次請求完後，将資料放入本地緩存。
那麼在 60 秒以内用戶端再發送請求，都不會請求應用伺服器，而是從本地緩存中直接傳回資料。如果兩次請求相隔時間超過了 60 秒，那麼就需要通過伺服器擷取資料。
1.2. 對比緩存
需要對比前後兩次的緩存标志來判斷是否使用緩存。浏覽器第一次請求時，伺服器會将緩存辨別與資料一起傳回，浏覽器将二者備份至本地緩存庫中。浏覽器再次請求時，将備份的緩存辨別發送給伺服器。
伺服器根據緩存辨別進行判斷，如果判斷資料沒有發生變化，把判斷成功的 304 狀态碼發給浏覽器。
這時浏覽器就可以使用緩存的資料來。伺服器傳回的就隻是 Header，不包含 Body。
下面介紹兩種辨別規則：
1.2.1. Last-Modified/If-Modified-Since 規則
在用戶端第一次請求的時候，伺服器會傳回資源最後的修改時間，記作 Last-Modified。用戶端将這個字段連同資源緩存起來。
Last-Modified 被儲存以後，在下次請求時會以 Last-Modified-Since 字段被發送。
當用戶端再次請求伺服器時，會把 Last-Modified 連同請求的資源一起發給伺服器，這時 Last-Modified 會被命名為 If-Modified-Since，存放的内容都是一樣的。
伺服器收到請求，會把 If-Modified-Since 字段與伺服器上儲存的 Last-Modified 字段作比較：
若伺服器上的 Last-Modified 最後修改時間大于請求的 If-Modified-Since，說明資源被改動過，就會把資源（包括 Header+Body）重新傳回給浏覽器，同時傳回狀态碼 200。
若資源的最後修改時間小于或等于 If-Modified-Since，說明資源沒有改動過，隻會傳回 Header，并且傳回狀态碼 304。浏覽器接受到這個消息就可以使用本地緩存庫的資料。
注意：Last-Modified 和 If-Modified-Since 指的是同一個值，隻是在用戶端和伺服器端的叫法不同。
1.2.2. ETag / If-None-Match 規則
用戶端第一次請求的時候，伺服器會給每個資源生成一個 ETag 标記。這個 ETag 是根據每個資源生成的唯一 Hash 串，資源如何發生變化 ETag 随之更改，之後将這個 ETag 傳回給用戶端，用戶端把請求的資源和 ETag 都緩存到本地。
ETag 被儲存以後，在下次請求時會當作 If-None-Match 字段被發送出去。
在浏覽器第二次請求伺服器相同資源時，會把資源對應的 ETag 一并發送給伺服器。在請求時 ETag 轉化成 If-None-Match，但其内容不變。
伺服器收到請求後，會把 If-None-Match 與伺服器上資源的 ETag 進行比較：
如果不一緻，說明資源被改動過，則傳回資源（Header+Body），傳回狀态碼 200。
如果一緻，說明資源沒有被改過，則傳回 Header，傳回狀态碼 304。浏覽器接受到這個消息就可以使用本地緩存庫的資料。
注意：ETag 和 If-None-Match 指的是同一個值，隻是在用戶端和伺服器端的叫法不同。
2. CDN 緩存
HTTP 緩存主要是對靜态資料進行緩存，把從伺服器拿到的資料緩存到用戶端/浏覽器。
如果在用戶端和伺服器之間再加上一層 CDN，可以讓 CDN 為應用伺服器提供緩存，如果在 CDN 上緩存，就不用再請求應用伺服器了。并且 HTTP 緩存提到的兩種政策同樣可以在 CDN 伺服器執行。
CDN 的全稱是 Content Delivery Network，即内容分發網絡。
讓我們來看看它是如何工作的吧：
用戶端發送 URL 給 DNS 伺服器。
DNS 通過域名解析，把請求指向 CDN 網絡中的 DNS 負載均衡器。
DNS 負載均衡器将最近 CDN 節點的 IP 告訴 DNS，DNS 告之用戶端最新 CDN 節點的 IP。
用戶端請求最近的 CDN 節點。
CDN 節點從應用伺服器擷取資源傳回給用戶端，同時将靜态資訊緩存。注意：用戶端下次互動的對象就是 CDN 緩存了，CDN 可以和應用伺服器同步緩存資訊。
CDN 接受用戶端的請求，它就是離用戶端最近的伺服器，它後面會連結多台伺服器，起到了緩存和負載均衡的作用。
3. 負載均衡緩存
說完用戶端（HTTP）緩存和 CDN 緩存，我們離應用服務越來越近了，在到達應用服務之前，請求還要經過負載均衡器。
雖說它的主要工作是對應用伺服器進行負載均衡，但是它也可以作緩存。可以把一些修改頻率不高的資料緩存在這裡，例如：使用者資訊，配置資訊。通過服務定期重新整理這個緩存就行了。
以 Nginx 為例，我們看看它是如何工作的：
使用者請求在達到應用伺服器之前，會先通路 Nginx 負載均衡器，如果發現有緩存資訊，直接傳回給使用者。
如果沒有發現緩存資訊，Nginx 回源到應用伺服器擷取資訊。
另外，有一個緩存更新服務，定期把應用伺服器中相對穩定的資訊更新到 Nginx 本地緩存中。
4. 程序内緩存
通過了用戶端，CDN，負載均衡器，我們終于來到了應用伺服器。應用伺服器上部署着一個個應用，這些應用以程序的方式運作着，那麼在程序中的緩存是怎樣的呢？
程序内緩存又叫托管堆緩存，以 Java 為例，這部分緩存放在 JVM 的托管堆上面，同時會受到托管堆回收算法的影響。
由于其運作在記憶體中，對資料的響應速度很快，通常我們會把熱點資料放在這裡。
在程序内緩存沒有命中的時候，我們會去搜尋程序外的緩存或者分布式緩存。這種緩存的好處是沒有序列化和反序列化，是最快的緩存。缺點是緩存的空間不能太大，對垃圾回收器的性能有影響。
目前比較流行的實作有 Ehcache、GuavaCache、Caffeine。這些架構可以很友善的把一些熱點資料放到程序内的緩存中。
這裡我們需要關注幾個緩存的回收政策，具體的實作架構的回收政策會有所不同，但大緻的思路都是一緻的：
FIFO（First In First Out）：先進先出算法，最先放入緩存的資料最先被移除。
LRU（Least Recently Used）：最近最少使用算法，把最久沒有使用過的資料移除緩存。
LFU（Least Frequently Used）：最不常用算法，在一段時間内使用頻率最小的資料被移除緩存。
在分布式架構的今天，多應用中如果采用程序内緩存會存在資料一緻性的問題。
這裡推薦兩個方案：
消息隊列修改方案
Timer 修改方案
4.1. 消息隊列修改方案
應用在修改完自身緩存資料和資料庫資料之後，給消息隊列發送資料變化通知，其他應用訂閱了消息通知，在收到通知的時候修改緩存資料。
4.2. Timer 修改方案
為了避免耦合，降低複雜性，對“實時一緻性”不敏感的情況下。每個應用都會啟動一個 Timer，定時從資料庫拉取最新的資料，更新緩存。
不過在有的應用更新資料庫後，其他節點通過 Timer 擷取資料之間，會讀到髒資料。這裡需要控制好 Timer 的頻率，以及應用與對實時性要求不高的場景。
程序内緩存有哪些使用場景呢？
場景一：隻讀資料，可以考慮在程序啟動時加載到記憶體。當然，把資料加載到類似 Redis 這樣的程序外緩存服務也能解決這類問題。
場景二：高并發，可以考慮使用程序内緩存，例如：秒殺。
5. 分布式緩存
說完程序内緩存，自然就過度到程序外緩存了。與程序内緩存不同，程序外緩存在應用運作的程序之外，它擁有更大的緩存容量，并且可以部署到不同的實體節點，通常會用分布式緩存的方式實作。
分布式緩存是與應用分離的緩存服務，最大的特點是，自身是一個獨立的應用/服務，與本地應用隔離，多個應用可直接共享一個或者多個緩存應用/服務。
既然是分布式緩存，緩存的資料會分布到不同的緩存節點上，每個緩存節點緩存的資料大小通常也是有限制的。
資料被緩存到不同的節點，為了能友善的通路這些節點，需要引入緩存代理，類似 Twemproxy。他會幫助請求找到對應的緩存節點。
同時如果緩存節點增加了，這個代理也會隻能識别并且把新的緩存資料分片到新的節點，做橫向的擴充。
為了提高緩存的可用性，會在原有的緩存節點上加入 Master/Slave 的設計。當緩存資料寫入 Master 節點的時候，會同時同步一份到 Slave 節點。
一旦 Master 節點失效，可以通過代理直接切換到 Slave 節點，這時 Slave 節點就變成了 Master 節點，保證緩存的正常工作。
每個緩存節點還會提供緩存過期的機制，并且會把緩存内容定期以快照的方式儲存到檔案上，友善緩存崩潰之後啟動預熱加載。
5.1. 高性能
當緩存做成分布式的時候，資料會根據一定的規律配置設定到每個緩存應用/服務上。
如果我們把這些緩存應用/服務叫做緩存節點，每個節點一般都可以緩存一定容量的資料，例如：Redis 一個節點可以緩存 2G 的資料。
如果需要緩存的資料量比較大就需要擴充多個緩存節點來實作，這麼多的緩存節點，用戶端的請求不知道通路哪個節點怎麼辦？緩存的資料又如何放到這些節點上？
緩存代理服務已經幫我們解決這些問題了，例如：Twemproxy 不但可以幫助緩存路由，同時可以管理緩存節點。
這裡有介紹三種緩存資料分片的算法，有了這些算法緩存代理就可以友善的找到分片的資料了。
5.1.1. 雜湊演算法
Hash 表是最常見的資料結構，實作方式是，對資料記錄的關鍵值進行 Hash，然後再對需要分片的緩存節點個數進行取模得到的餘數進行資料配置設定。
例如：有三條記錄資料分别是 R1，R2，R3。他們的 ID 分别是 01，02，03，假設對這三個記錄的 ID 作為關鍵值進行 Hash 算法之後的結果依舊是 01，02，03。
我們想把這三條資料放到三個緩存節點中，可以把這個結果分别對 3 這個數字取模得到餘數，這個餘數就是這三條記錄分别放置的緩存節點。
Hash 算法是某種程度上的平均放置，政策比較簡單，如果要增加緩存節點，對已經存在的資料會有較大的變動。
5.1.2. 一緻性雜湊演算法
一緻性 Hash 是将資料按照特征值映射到一個首尾相接的 Hash 環上，同時也将緩存節點映射到這個環上。
如果要緩存資料，通過資料的關鍵值（Key）在環上找到自己存放的位置。這些資料按照自身的 ID 取 Hash 之後得到的值按照順序在環上排列。
如果這個時候要插入一條新的資料其 ID 是 115，那麼就應該插入到如下圖的位置。
同理如果要增加一個緩存節點 N4 150，也可以放到如下圖的位置。
這種算法對于增加緩存資料，和緩存節點的開銷相對比較小。
5.1.3. Range Based 算法
這種方式是按照關鍵值（例如 ID）将資料劃分成不同的區間，每個緩存節點負責一個或者多個區間。跟一緻性哈希有點像。
例如：存在三個緩存節點分别是 N1，N2，N3。他們用來存放資料的區間分别是，N1(0, 100]， N2(100, 200]， N3(300, 400]。
那麼資料根據自己 ID 作為關鍵字做 Hash 以後的結果就會分别對應放到這幾個區域裡面了。
5.2. 可用性
根據事物的兩面性，在分布式緩存帶來高性能的同時，我們也需要重視它的可用性。那麼哪些潛在的風險是我們需要防範的呢？
5.2.1. 緩存雪崩
當緩存失效，緩存過期被清除，緩存更新的時候。請求是無法命中緩存的，這個時候請求會直接回源到資料庫。
如果上述情況頻繁發生或者同時發生的時候，就會造成大面積的請求直接到資料庫，造成資料庫通路瓶頸。我們稱這種情況為緩存雪崩。
從如下兩方面來思考解決方案：
緩存方面：
避免緩存同時失效，不同的 key 設定不同的逾時時間。
增加互斥鎖，對緩存的更新操作進行加鎖保護，保證隻有一個線程進行緩存更新。緩存一旦失效可以通過緩存快照的方式迅速重建緩存。對緩存節點增加主備機制，當主緩存失效以後切換到備用緩存繼續工作。
設計方面，這裡給出了幾點建議供大家參考：
熔斷機制：某個緩存節點不能工作的時候，需要通知緩存代理不要把請求路由到該節點，減少使用者等待和請求時長。
限流機制：在接入層和代理層可以做限流，當緩存服務無法支援高并發的時候，前端可以把無法響應的請求放入到隊列或者丢棄。
隔離機制：緩存無法提供服務或者正在預熱重建的時候，把該請求放入隊列中，這樣該請求因為被隔離就不會被路由到其他的緩存節點。
如此就不會因為這個節點的問題影響到其他節點。當緩存重建以後，再從隊列中取出請求依次處理。
5.2.2. 緩存穿透
緩存一般是 Key，Value 方式存在，一個 Key 對應的 Value 不存在時，請求會回源到資料庫。
假如對應的 Value 一直不存在，則會頻繁的請求資料庫，對資料庫造成通路壓力。如果有人利用這個漏洞攻擊，就麻煩了。
解決方法：如果一個 Key 對應的 Value 查詢傳回為空，我們仍然把這個空結果緩存起來，如果這個值沒有變化下次查詢就不會請求資料庫了。
将所有可能存在的資料哈希到一個足夠大的 Bitmap 中，那麼不存在的資料會被這個 Bitmap 過濾器攔截掉，避免對資料庫的查詢壓力。
5.2.3. 緩存擊穿
在資料請求的時候，某一個緩存剛好失效或者正在寫入緩存，同時這個緩存資料可能會在這個時間點被超高并發請求，成為“熱點”資料。
這就是緩存擊穿問題，這個和緩存雪崩的差別在于，這裡是針對某一個緩存，前者是針對多個緩存。
解決方案：導緻問題的原因是在同一時間讀/寫緩存，是以隻有保證同一時間隻有一個線程寫，寫完成以後，其他的請求再使用緩存就可以了。
比較常用的做法是使用 mutex（互斥鎖）。在緩存失效的時候，不是立即寫入緩存，而是先設定一個 mutex（互斥鎖）。當緩存被寫入完成以後，再放開這個鎖讓請求進行通路。
總結：緩存設計有五大政策，從使用者請求開始依次是：
HTTP 緩存
CDN 緩存
負載均衡緩存
程序内緩存
分布式緩存
其中，前兩種緩存靜态資料，後三種緩存動态資料：
HTTP 緩存包括強制緩存和對比緩存。
CDN 緩存和 HTTP 緩存是好搭檔。
負載均衡器緩存相對穩定資源，需要服務協助工作。
程序内緩存，效率高，但容量有限制，有兩個方案可以應對緩存同步的問題。
分布式緩存容量大，能力強，牢記三個性能算法并且防範三個緩存風險。