1. 分散式緩存

1.1. 緩存存在於應用程式的許多地方

• 1.1.1. 行應用程式的CPU具有高速多級硬體緩存，可以減少相對較慢的主記憶體訪問

• 1.1.2. 資料庫引擎可以利用主記憶體來緩存數據存儲的內容，這樣在許多情況下查詢就可以不用訪問速度相對較慢的磁碟

1.2. 分散式緩存是可擴展系統的重要組成部分

• 1.2.1. 緩存使耗時的查詢和計算結果能夠在後續請求中低成本地重用

• 1.2.2. 由於不必為每個請求重建緩存結果，系統的容量增加了，並且可以擴展來處理更大的工作負載

1.3. 應用緩存依賴業務邏輯，業務邏輯使用分散式緩存將預計算結果的緩存和訪問結合在一起

1.4. Web緩存充分利用HTTP協議中內置的機制在網路提供的基礎設施中緩存結果

1.5. 緩存是任何可擴展分佈系統的重要組成部分

• 1.5.1. 緩存將許多客戶端請求的信息存儲在記憶體中，並利用這些信息為客戶端請求提供服務

1.6. 使用分散式緩存的應用緩存是可擴展系統中最常用的緩存方法

1.7. 互聯網還有內建的多級緩存基礎設施

• 1.7.1. HTTP緩存使用得當的話可以顯著減少下游服務和資料庫的請求負載

1.8. 緩存是軟體和系統的一個成熟領域

1.9. CDN本身就是一個複雜的、針對供應商的主題

• 1.9.1. 它們適用於用戶群在地理上分散、內容需要快速交付的富媒體網站

2. 應用緩存

2.1. 應用緩存旨在通過將查詢和計算的結果存儲在記憶體中來提高請求響應能力，以便為後續的請求提供服務

• 2.1.1. 緩存可以減輕資料庫讀取流量的負擔，因為許多查詢都可以直接從緩存中獲取結果

• 2.1.2. 緩存最終效果是減少了服務和資料庫的計算負擔，併為更多請求創造了空間或容量

2.2. 緩存需要額外的資源和成本來存儲緩存結果

• 2.2.1. 與升級資料庫和服務節點以應對更高的請求負載相比，設計良好的緩存方案成本較低

2.3. 應用級緩存採用專用的分散式緩存引擎

• 2.3.1. 主流技術

• 2.3.1.1. memcached

• 2.3.1.2. Redis

• 2.3.1.3. 兩者本質上都是分散式記憶體哈希表，為存儲代表資料庫查詢結果或下游服務API調用結果的任意數據（字元串、對象）而設計

2.4. 緩存常見的使用場景是存儲用戶會話數據、動態網頁和資料庫查詢結果

2.5. 緩存命中

• 2.5.1. 如果可用，它會將緩存的內容作為結果返回

• 2.5.2. 緩存命中率應該是多少並沒有一個硬性的規定，因為它取決於構建緩存內容的成本和緩存項的更新頻率

• 2.5.2.1. 理想的緩存設計應該是讀取頻率遠高於更新頻率

2.6. 如果數據不在緩存中，即緩存未命中，服務將從資料庫中查詢所請求的數據並將查詢結果寫入緩存，後續的客戶端請求無須查詢資料庫即可使用這些數據

• 2.6.1. 當項目需要經常更新時，緩存未命中的成本可能會抵消緩存帶來的好處

2.7. 當緩存值有效時，所有請求都會使用它

• 2.7.1. 無須為每個請求調用執行耗時的電梯等待時間的計算

2.8. 使用TTL之類的過期時間是使緩存內容失效的一種常用方法

• 2.8.1. 確保了服務不會向客戶端提供過期的結果

• 2.8.2. 使系統能夠對緩存內容進行一些控制，緩存的空間通常是有限的

2.9. 如果緩存項沒有定期刷新，緩存將會填滿

• 2.9.1. 在這種情況下，緩存將採用最近最少使用或最少訪問之類的策略來選擇要剔除的緩存條目併為更新、更及時的結果騰出空間

2.10. 應用緩存可以顯著提高吞吐量、減少延遲並提高客戶端應用程式的響應能力

2.11. 一般的設計原則是最大化緩存命中率和最小化緩存未命中率

• 2.11.1. 當發生緩存未命中時，必須通過查詢資料庫或下游服務來滿足請求

• 2.11.2. 然後可以將請求的結果寫入緩存，用於後續的訪問

2.12. 應用級緩存也被稱為旁路緩存(cache-aside)模式

• 2.12.1. 如果所需的結果在緩存中可用，則應用程式代碼會高效地繞過數據存儲系統

• 2.12.2. 旁路緩存策略的一個顯著優勢是它對緩存故障更具彈性

• 2.12.3. 在緩存不可用的情況下，所有請求基本上都當作緩存未命中來處理

• 2.12.4. 擴展Redis和memcached之類的旁路緩存平臺非常簡單，得益於其簡單的分散式哈希表模型

• 2.12.5. 旁路緩存模式是大規模可擴展系統使用的主要方法

2.13. 緩存提供了“魔法”來確保緩存與後端存儲系統進行適當的交互

2.14. NCache支持提供者介面(provider interface)由應用程式實現

• 2.14.1. 介面會在通讀緩存未命中和通寫緩存寫入時自動調用

• 2.14.2. 通讀、通寫和後寫策略需要這樣一種緩存技術，該技術可以通過特定應用的處理程式進行擴充，以便在應用程式訪問緩存時執行資料庫的讀取和寫入

3. 通讀緩存

3.1. 應用通過訪問緩存來滿足所有請求

3.2. 如果所需的數據在緩存中不可用，則調用載入器來訪問數據系統並將結果載入到緩存中以供應用使用

4. 通寫緩存

4.1. 應用總是將更新寫入緩存

4.2. 當緩存更新時，將調用寫入器將新的緩存值寫入資料庫

4.3. 當資料庫更新後，應用可以完成請求

5. 後寫緩存

5.1. 回寫緩存

5.2. 與通寫緩存類似，只是應用不等待將值從緩存寫入資料庫

5.3. 這種模式是以可能丟失更新（如果緩存伺服器在資料庫更新完成之前崩潰）為代價來提高請求響應能力

5.4. 是大多數資料庫引擎內部使用的策略

6. Web緩存

6.1. Web緩存會在定義的時間段記憶體儲給定資源（例如，網頁或圖像）的副本

6.2. 由於緩存在物理上更靠近客戶端，因此請求的延遲會更低

6.3. 邊緣緩存，也叫內容分髮網絡(CDN)

• 6.3.1. 位於全球多個戰略地理位置

• 6.3.2. 可以緩存靠近客戶端的頻繁訪問的數據

• 6.3.3. 邊緣緩存由CDN提供商在全球範圍內部署

• 6.3.4. Akamai是最早的CDN提供商，擁有2000多個站點，併在全球提供高達30%的互聯網流量

• 6.3.5. 對於擁有全球用戶的富媒體站點，邊緣緩存是必不可少的

6.4. 緩存通常只存儲GET請求的結果，緩存鍵是與GET關聯的URI

• 6.4.1. 任何具有所請求資源副本的緩存都可以響應請求

6.5. Cache-Control

• 6.5.1. 客戶端請求和服務響應可以使用Cache-Control HTTP標頭來定義緩存應該如何利用感興趣的資源

6.6. Expires和Last-Modified HTTP標頭與max-age指令互相配合以控制緩存數據的保留時間

• 6.6.1. 緩存存儲的資源是有限的

• 6.6.2. 當請求訪問一個有效資源時，緩存會用本地存儲的結果提供服務，而無須聯繫源伺服器

6.7. Etag

• 6.7.1. 可用於控制緩存項新鮮度的指令

• 6.7.2. Etag是一個不透明的值，Web緩存可以使用它來檢查緩存的資源是否仍然有效

6.8. Web緩存如果能有效使用，可以顯著減少延遲並節省網路帶寬，對於圖像和文檔等大型項目尤其明顯

6.9. Web緩存對部署靜態數據（圖像、視頻和音頻流）以及不經常變化的數據（如天氣報告）最為有效

• 6.9.1. Squid和Varnish等代理緩存廣泛部署在互聯網上

6.10. HTTP緩存與代理和邊緣緩存相結合所提供的強大功能是構建可擴展應用的寶貴工具