讀構建可擴充套件分散式系統：方法與實踐05分散式快取

躺柒發表於2024-09-16
套件分散式快取

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快取與代理和邊緣快取相結合所提供的強大功能是構建可擴充套件應用的寶貴工具

相關文章