本文主要是關於cache的介紹、用例、策略
Data Centre
前言
你有沒有注意到，如果你在緩慢的互聯網中連接和瀏覽一個網站，文本加載之前，任何高質量的圖像都不會加載。然而，在您隨後訪問同一網站時，您會發現頁面呈現很快。當你訪問一個全新的網站，它需要更多的時間來加載比經常訪問的網站，如微信或阿里巴巴。你知道為什麼會這樣嗎?答案是緩存。
Instagram page on a slow internet connection
上面的圖片是我的微博頁面在慢速互聯網連接時的樣子。如您所見，文本數據顯示，而您無法看到圖像，因為頁面仍在呈現。
為用戶提供最佳體驗對於提高用戶留存率和參與度非常重要。在當今競爭激烈的世界中，企業會因為糟糕的用戶體驗而受到影響。想象一下，你正在任何一個視頻流媒體網站上看你最喜歡的電視劇，但是視頻一直在緩衝。你會在這樣的網站上繼續訂閱嗎?
緩存的工作原理是“引用的局部性”。緩存充當數據的本地存儲，以加速查找或檢索。緩存的主要目標是減少讀取延遲並放大任何應用程序的吞吐量。在下一節中，我們來看一個真實的類比。
現實世界中緩存的類比
假設你每天都做飯。你需要不同的配料、蔬菜、香料等來準備食物。但是你每天都去超市買這個嗎?這太麻煩，太耗時了。所以，你要先檢查你的廚房或冰箱，以防你的雜貨堆得太滿。這樣就不用去逛超市了。
Refrigerator behaves as a Cache for vegetables
在這裡，你的冰箱就像是你儲存蔬菜的地方。使用緩存的最大好處是節省了時間，可以快速準備食物。
緩存如何工作
後端應用程序通常將數據存儲在數據庫中。當客戶端獲取任何數據時，應用程序查詢數據庫，獲取數據並將其返回給用戶。數據庫服務器作為一個單獨的進程運行，可以在與應用服務器不同的計算機上運行。
Application Server fetching data from DB
從數據庫讀取數據非常耗時，因為需要網絡調用和IO操作才能從文件系統獲取數據。如果數據存儲在緩存中，讀取操作將非常快。當用戶重複請求相同的數據時，從緩存中獲取數據比從數據庫中獲取數據更有意義。
例如:如果一條微博病毒式傳播，所有的客戶端都會嘗試獲取同一條微博的數據。由於微博擁有數百萬用戶，使用緩存將為數據庫節省數百萬次調用。
此外，緩存還減少了數據庫的負載。如果在緩存中找到數據，就會保存數據庫調用，從而減少數據庫的壓力。簡單地說，可以將緩存看作存儲鍵-值對的哈希表。
下圖說明了從緩存中讀取數據的過程:
Process of reading from Cache
緩存的核心概念
TTL (Time to Live)
可以存儲在緩存中的數據量是有限制的。有必要刪除應用服務器不再需要的緩存中的條目。
在Netflix(網飛)，服務器將緩存最頻繁觀看或最熱門的節目。它不需要存儲那些收視率隨著時間而下降的節目。
例如:在我寫這篇文章的時候，收藏像《王牌對王牌》這樣的電視節目比收藏像《流浪地球》這樣的電影更有意義。
緩存算法
根據應用程序訪問數據的方式，緩存可能在某個時間點被填滿。因此，我們需要想出一個策略來從緩存中刪除數據，並將其替換為將來更有可能被訪問的數據。
有多個緩存清除策略，如LRU(最近最少使用)、LFU(最不經常使用)、MRU(最近使用)。這些策略使用預定義的邏輯從緩存中刪除數據。我們將在下一節中討論上述每一項。
LRU(最近最少使用)
此策略從緩存中刪除最近最少使用的項。一旦緩存滿了，最近最少使用的條目就會被從緩存中移除，而最近使用的條目則會被添加到緩存中。
你可以想象微信把名人的照片儲存在緩存裡。關注者的數據訪問模式是這樣的，他們對最近的照片很感興趣。當緩存被填滿時，它將踢出最近添加的照片。
LFU(最少使用)
LFU跟蹤數據項被訪問的頻率或次數。當緩存大小超過給定的閾值時，它將以最低的頻率驅逐該條目。
當你在發短信的時候輸入任何一個單詞，你的手機就會開始提示你可以選擇多個單詞，而不是輸入整個單詞。在內部，你的手機軟件會對你輸入的所有單詞及其頻率進行緩存。
Phone’s software recommending words to complete
緩存稍後將以最低的頻率清除該單詞。如果多個單詞之間存在關聯，那麼最近最少使用的單詞將被清除。在上面的手機例子中，如果你開始使用“功能”，“功能”，“羽毛”等詞，它將停止向你提示“壯舉”這個詞(因為這將被從緩存中刪除)。
MRU(最近使用)
在MRU中，刪除最近使用的條目，並優先將舊的條目保留在緩存中。如果數據訪問模式使用戶不太可能查看最近的條目，則此策略用於清除。讓我們看一個例子。
Tinder Left/Right Swipe uses the MRU policy
像陌陌這樣的約會應用通常會緩存用戶的所有潛在匹配對象。當用戶向左或向右滑動個人資料時，應用程序不應該再次向用戶推薦相同的個人資料。如果發生這種情況，將會導致糟糕的用戶體驗。
有必要對最近觀察到的條目進行剔除。應用程序必須刪除向右或向左滑動的配置文件的緩存項。
緩存類型
Write Through Cache
顧名思義，數據首先寫入緩存，然後寫入數據庫。這確保了緩存中的數據與數據庫中的數據之間的一致性。在緩存上執行的每次讀操作都是在最近的寫操作之後進行的。
Write Through Cache
但是，這種方法的缺點是應用程序寫延遲增加。這種方法不適合寫得很多的系統。對於那些一旦數據被持久化到數據庫中就頻繁地重新讀取數據的應用程序來說，這是非常有用的。寫延遲可能會受到影響，但它可以通過較低的讀延遲和一致性得到補償
Write Back Cache
從上面可以看出，通過緩存進行寫操作並不適用於寫操作較多的系統，因為延遲可能會增加。另一種方法是先將數據寫入緩存，並將數據標記為已修改(稍後在DB中更新)。
Write Back Cache
異步作業可以定期讀取緩存中的所有修改項，並更新它們在數據庫中的相應值。這種方法既不會影響讀延遲，也不會影響寫延遲。唯一的缺點是緩存和數據庫之間的數據同步會有延遲。由於數據庫是事實的來源，從數據庫中讀取的任何應用程序都將讀取陳舊的條目。
像騰訊視頻這樣的網站使用回寫緩存來存儲任何視頻的瀏覽次數。為病毒視頻的每一個單獨的視圖更新數據庫將是昂貴的。將數據寫入緩存，然後將其同步到數據庫是更好的解決方案。使用回寫緩存可以確保較低的讀/寫延遲。
Write Around Cache
很少有後端應用程序不經常重新讀取最近的數據。在這種情況下，使用了寫入緩存。
Write Around Cache
在此策略中，數據庫在不寫入緩存的情況下更新。這不會加載緩存的數據不會被重新讀取。如果應用程序開始查詢最近的數據，就會導致緩存丟失。
以下是內存中緩存產品的開源列表
- Redis
- Memcached
- VoltDB
- Aerospike DBS
- Apache Ignite
- haproxy for cache
引用自
- List of In-memory databases [https://en.wikipedia.org/wiki/List_of_in-memory_databases]
- What is Caching? [https://www.cloudflare.com/learning/cdn/what-is-caching/]
- Distributed Caching [https://en.wikipedia.org/wiki/Distributed_cache]
- Types of Caches [https://www.geeksforgeeks.org/write-through-and-write-back-in-cache/]
閱讀更多 架構師之路 的文章
