架構設計（三）：引入快取
作者：Grey
原文地址：
快取是一個臨時儲存區域，如果請求的資料獲取代價比較高或者資料的訪問頻率比較高，則會把響應結果儲存在記憶體中，以便更快速地提供後續請求。
每次載入一個新的網頁，都要執行一次或多次資料庫呼叫來獲取資料。反覆呼叫資料庫會大大影響應用程式的效能。快取可以緩解這個問題，架構如下
在收到一個請求後，網路伺服器首先檢查快取是否有可用的響應。如果有它有，它就把資料發回給客戶。如果沒有，它就查詢資料庫，將響應儲存在快取，並將其發回給客戶端。這種快取策略被稱為"讀過式快取"。根據資料的型別、大小和訪問模式，還有其他的快取策略。與快取的互動也很簡單，因為大多數快取中介軟體都提供了適用於普通程式語言的 API。
快取層是一個臨時資料儲存層，比資料庫快得多。有一個獨立的快取層的好處有如下幾點
-
更好的系統效能，減少資料庫工作負載。
-
快取層也可以做獨立的擴充套件（叢集）。
使用快取的考慮因素如下
-
當要訪問的資料經常被讀取但不經常被修改時，可以考慮使用快取，因為快取的資料儲存在易失性記憶體中，所以快取伺服器並不是持久儲存資料的理想選擇。如果快取伺服器重新啟動，記憶體中的所有資料都會丟失。因此，重要的資料應該儲存在永續性資料儲存中。
-
過期策略。為快取設定過期策略是快取使用的最佳實踐。一旦快取的資料過期，它就會從快取中刪除。當沒有過期策略時，快取的資料將被永久地儲存在記憶體中。建議不要把過期日期定得太短，因為這將導致系統過於頻繁地從資料庫中重新載入資料；同時，建議不要使過期日期太長，因為資料會變得陳舊。
-
快取一致性。這就涉及到保持資料儲存和快取的資料同步。因為對資料儲存和快取的資料修改操作不在一個事務中。當跨區域擴充套件時，保持資料儲存和快取之間的一致性是一個挑戰。
-
單點故障預防。如果使用單個快取伺服器，這就可能會導致潛在的單點故障，單點故障（SPOF）是一個系統的一部分，如果它發生故障，將使整個系統停止工作，因此，建議在不同的資料中心設定多個快取伺服器以避免SPOF。可以參考架構設計（一）：從單伺服器模式到負載均衡設計，另一個推薦的方法是按一定的百分比超額配置所需的記憶體，這可以在記憶體使用量增加時提供一個緩衝。
-
驅逐策略。一旦快取已滿，任何向快取新增專案的請求都可能導致現有專案被刪除。這就是所謂的緩衝區驅逐。最小最近使用（LRU）是最流行的緩衝區驅逐策略。還有其他的驅逐策略，如最不常使用（LFU）或先進先出（FIFO）。