快取(Cache)機制 - 筆記

tags: cache database Interview Preparation scalibility

本站筆記已同步更新到我的個人網站囉! 歡迎參觀與閱讀，體驗不同的視覺感受!

• 快取(Cache)機制 - 筆記
  • Image Not Showing Possible Reasons The image file may be corruptedThe server hosting the image is unavailableThe image path is incorrectThe image format is not supported Learn More → 什麼是快取(Cache)
  • Image Not Showing Possible Reasons The image file may be corruptedThe server hosting the image is unavailableThe image path is incorrectThe image format is not supported Learn More → 快取的好處與使用情境
    • 好處
    • 使用情境
  • Image Not Showing Possible Reasons The image file may be corruptedThe server hosting the image is unavailableThe image path is incorrectThe image format is not supported Learn More → 快取置換策略(Cache Eviction Policies / Cache Replacement Policies)
    • LRU (Least Recently Used):
    • Most Recently Used (MRU):
    • Least Frequently Used (LFU):
    • FIFO (First In First Out):
  • 小結
  • 參考資料

什麼是快取(Cache)

當web app規模越來越大、使用者越來越多，頁面加載的時間也變得更久；因此，需要一個更快速的方式提供網站內容給使用者。快取提供了這種功能，快取指的是將資料儲存在具有高速特性的資料儲存層的一個過程，尤其針對可重複使用的資料，後續發送請求這些資料時，可以更有效率地重複使用之前擷取或運算過的資料。

快取的好處與使用情境

好處

• 提高性能(performance)：
  經由快取解析的請求，能夠快速地從快取中取得資料(對應的response)，稱為快取命中(cache hits)。 快取優先儲存需要高頻率取得的資料，減少需要重複從較慢速的儲存資源中(如硬碟)重複取得資料的需求，因此使用者發送出的請求可以更高效率的被解析。
• 減少伺服器流量負載(traffic load)：
  同樣的請求(例如網站首頁的商品圖)如果短時間內大量發送(如同時數百個使用者上線)，這樣的流量會造成伺服器的負擔；如果把這些圖片透過快取機制讀取，可以提升使用者獲得回應的速度，同時避免伺服器浪費效能處理重複的請求。
• 改善資料庫性能：
  研究指出，獲得伺服器回應(response)的時間中，很大一部份都花在等待資料庫回應；即使資料庫查詢指令是高效率的，處理每個指令(尤其是需要頻繁取得的物件)也會快速增加時間成本。解決此問題的一個方法是繞過指令處理，使用預先計算過的快取解果。
• 提高內容的可用性(availability)：
  即使原始資料庫暫時關閉，快取也可以用作保留某些資料可用性的一種方式。

使用情境

HTTP Web App的分層(layer)

圖片來源：AWS

常見應用快取的分層：

客戶端層快取:

在用戶端的平台應用快取，例如瀏覽器快取。大多數瀏覽器都有一個內建的小型快取，允許Web app儲存頁面和資料的臨時副本（例如圖像、臨時數據），以便用戶不必多次檢索相同的資訊。然而，開發者對這種類型的快取的控制能力最少，因為它的功能（例如大小、速度）由維護瀏覽器的公司（例如Google Chrome、Firefox）管理；另外因為現代使用者常透過多平台(web, Android app, iOS app等)互動，若在客戶端實作快取，則必須製作多種不同快取，維護成本較高。

DNS層快取：

DNS將網域解析至IP位置，因此DNS快取旨在減少DNS伺服器查詢IP時所花費的時間，將作業系統或瀏覽器中所取得的歷史網域記錄存入快取，下次解析同樣網域時，就可從快取中取得解析結果，不需重複詢問DNS伺服器。

Web content層快取：

加速從 Web/應用程式伺服器擷取 Web 內容，如圖片等，管理 Web工作階段 (伺服器端)。常見的如CDN(Content Delivery Network)快取、反向代理伺服器等。

應用程式層快取：

應用程式層快取是應用在伺服器端的快取。我們可以使用應用程式層快取來儲存瀏覽器內容或類似的數據。這種類型的快取可以幫助緩解高流量期間的伺服器壓力。與客戶端層快取不同，系統管理者對應用程式層快取有較高的控制能力。

資料庫層快取：

資料庫層快取可以儲存最近的資料庫查詢及其對應的回應，以幫助提高查詢回應速度，降低與資料庫查詢請求相關的延遲。資料庫層快取還可以減少資料庫使用並在資料庫發生故障時，提供部分數據可用性。

快取置換策略(Cache Eviction Policies / Cache Replacement Policies)

為了使快取更有效，我們希望能夠將快取命中(cache hits)極大化，並減少快取失誤(cache miss)；也就是希望當請求傳入時，盡可能提高從快取中回傳資料的機率。而因為快取的生產和購買成本高，快取的小尺寸也限制了我們可以存的資料量，因此，需要考慮隨著時間的推移，應該保留或刪除哪些數據，也就是當快取滿了該如何處理。這是快取置換策略(Cache Eviction Policy) 的核心目的，這些策略是用於管理快取中資料的演算法。

常見的策略/演算法：

LRU (Least Recently Used):

LRU會替換/移除最長時間未發送請求的項目，根據上次使用的時間戳計，最久沒被存取的快取資料會先被移除，才有空間放入新的資料。每次發送請求時，LRU演算法都會更新該請求對象的時間戳，並將其移至快取頂部；當需要從快取中移除某些項目時，它將分析快取的狀態並刪除列表底部的項目。

Most Recently Used (MRU):

MRU策略本質上與LRU相反，它也是根據快取上次訪問的時間來決定先被移除的快取資料，但它和LRU的不同之處在於，它從快取中移除最近造訪的對象，而不是最近最少使用的對象。
MRU在以下情境十分實用：當一個快取項目越久沒被使用，他就越有可能在接下來被使用（換句話說，最近被使用的對象，不可能很快再次被使用）。例如，預訂航班座位後，立即從快取中刪除該預訂的座位，因為它們不再與後續的預訂相關。

Least Frequently Used (LFU):

LFU將刪除自存入快取以來最少使用的項目。LFU透過在每次存取快取對象時計數來執行分析，以便在需要從快取中移出項目時與其他對象進行比較。LFU在快取對象的訪問模式不經常變動的情況下表很實用，並且相較於MRU或LRU，儲存計數比儲存時間戳記消耗更少的記憶體。
然而，當某個項目被頻繁使用之後，使用次數急遽下降時，LFU會造成該項目被卡在快取中不會消失(儘管已經不再被使用)，而新加入或使用次數低的資料則不斷在變動。

FIFO (First In First Out):

FIFO策略會按照項目被放入快取中的順序移除，也就是最先加入的資料，在快取滿的時候，會優先被移除，而不考慮它們被使用的頻率或次數。

小結

以上簡單介紹快取及常見的置換策略，更多策略可以參考Wikipedia。

---

參考資料

• 快取概觀-AWS
• 極限加速！Web 開發者不能不知道的 Cache 大補帖！
• Caching In Node.js Applications
• 快取的置換策略(Cache replacement policies)
• [不是工程師] 讓網站速度飛快的秘密，你了解什麼是網頁快取(Cache)嗎?
• 什麼是快取 (Cache)？快取 (Cache) 的機制為何？
• 提升程式存取資料速度的必殺技

　本站內容僅為個人學習記錄，如有錯誤歡迎留言告知、交流討論！