在昨天我們談完如何使用Azure Kubernetes Service部署Container應用程式後
今天我們來聊聊Azure Cache for Redis,若你有在佈署Instant Messaging
服務,建議可以使用Azure Cache for Redis可以快速傳送和存取,確保訊息的
圖片和文字會一起傳送,使用caching read-only data with Redis來最佳化
Web應用程式,Redis Cache是可作為database,cache或message broker的
記憶體內部資料結構存放區。
有些時候您必須保證可同時執行多個作業。 例如,在Onf 的即時訊息應用程式中
,使用者可以傳送:個別圖片、個別文字簡訊,或圖片和文字簡訊。 當使用者選擇
一起傳送圖片和文字簡訊時,您必須確定群組的其他成員能夠同時接收它們,因為
如果圖片和文字簡訊未一起接收,就有可能會在圖片和文字簡訊之間傳送個別訊息
。 這樣會讓整體對話令人感到困惑。
Redis 中的交易運作方式,是將多個要執行的命令以群組方式排入佇列。 當執行
交易時,在交易中排入佇列的命令保證會執行,而不會有來自其他用戶端的任何
其他命令交錯在其當中,若要開始交易區塊,請輸入 MULTI 命令。 後續的命令會
被排入佇列,而不會立刻執行。 執行 EXEC 命令會將所有已排入佇列的命令當作
交易單位來執行。 如果你決定要在命令正在排入佇列時中止開啟的交易,執行
DISCARD 命令將會關閉交易區塊,而不會執行「任何」已排入佇列的命令。
Redis 交易不支援復原的概念。 如果您使用不正確的語法將命令排入佇列至交易
區塊中,區塊將會維持開啟,但如果您嘗試以 EXEC 執行,將會自動捨棄該交易
區塊。 在交易「執行期間」(呼叫 EXEC 之後) 失的命令不會導致交易中止
或復原 — Redis 仍會執行所有命令,並將交易視為已成功完成。
資料不一定都要永久保存,有時候你會想要在特定時間刪除資料,例如在你的即時
訊息應用程式中,使用者可以設定群組聊天的顯示名稱。不過你想要在一小時後
重設名稱,你可以撰寫自己的伺服器端邏輯 (設定一小時計時器並重設名稱)來完成
此動作。 不過Azure Cache for Redis 支援資料到期,此功能會自動完成此
動作,不需要撰寫額外的邏輯。
資料到期這個功能,可以在在設定的一段時間之後,自動刪除快取中的索引鍵和值。
資料到期常用於儲存資料存留期較短的情況中,因為Azure Cache for Redis是
記憶體內部資料庫,而且可用的記憶體不像您儲存在磁碟上時一樣多,因為您在
使用Azure Cache for Redis時的儲存空間有限,你應該只儲存重要資料。
如果資料不需要存在太長時間,請務必設定到期時間。
有不同的命令可以實作及管理 Azure Cache for Redis 中的資料到期:
-EXPIRE:設定機碼的逾時 (以秒為單位)
-PEXPIRE:設定索引鍵的逾時 (以毫秒為單位)
-EXPIREAT:使用絕對 Unix 時間戳記 (以秒為單位) 設定索引鍵的逾時
-PEXPIREAT:使用絕對 Unix 時間戳記 (以毫秒為單位) 設定索引鍵的
逾時
-TTL:傳回索引鍵存留的剩餘時間 (以秒為單位)
-PTTL**:傳回索引鍵存留的剩餘時間 (以毫秒為單位)
-PERSIST:讓機碼永不到期
記憶體是Azure Cache for Redis最重要的資源,因為它是記憶體內部資料庫。
當你開始新增超過可用記憶體數量的資料時會遇到問題。,Azure Cache for
Redis支援eviction policies(收回原則),policie會指出當用盡記憶體時,
應該如何處理資料。
eviction policy是一個計劃,決定當你超過可用記憶體數量上限時,如何管理
你的資料,例如,使用收回原則,你就可以告訴 Azure Cache for Redis刪除
隨機索引鍵,以讓出空間給新的資料插入。
Azure Cache for Redis 提供的收回原則有六種。 這些原則都會在你於記憶體
用盡的情況下嘗試插入資料時,執行動作。
-noeviction: 無收回原則。 如果您嘗試插入資料,則會傳回錯誤訊息。
-allkeys-lru: 移除最近最少使用的索引鍵。
-allkeys-random: 移除隨機索引鍵。
-volatile-lru: 在已設定到期的所有索引鍵中,移除最近最少使用的
索引鍵。
-volatile-ttl: 根據設定的到期時間,移除具有最短存留時間的索引鍵
-volatile-random: 移除已設定到期的隨機索引鍵。
建置應用程式時,你想要提供絕佳的使用者體驗,而其中一部分就是快速擷取資料
。 從資料庫擷取資料通常是緩慢的程序,而且如果經常讀取此資料,則可能會
造成不好的使用者體驗。 另行快取模式描述如何搭配資料庫實作快取,以盡快
傳回最常存取的資料。
cache-aside pattern模式指定當你需要從資料來源(例如關聯式資料庫)擷取
資料時,你應該先檢查快取中的資料,如果資料在你的快取中,則使用它。
如果資料不在你的快取中,則查詢資料庫,並在將資料傳回給使用者時,將它新增
至快取。 接著,你就可以在下次需要資料時,從快取存取該資料。
從資料庫讀取資料通常是緩慢的程序。 這涉及到編譯複雜的查詢、準備查詢執行
計畫、執行查詢,然後準備結果。 在某些情況下,此程序也可能會從磁碟讀取
資料。 你可以在資料庫層級進行最佳化,例如預先編譯查詢,以及將部分資料
載入記憶體。 不過,從資料庫擷取資料時,一律會執行查詢及準備結果。
使用另行快取模式可解決這個問題。 在另行快取模式中,仍有應用程式和資料庫
,但現在也有快取,快取會將其資料儲存在記憶體中,因此不需要與檔案系統互動
,快取也會以非常簡單的資料結構(例如索引鍵值組)來儲存資料,因此不需要執行
複雜的查詢來收集資料,或在寫入資料時維護索引。 基於上述原因,快取的效能
一般會高於資料庫。 當您使用應用程式時,它會嘗試先從快取讀取資料。 如果
要求的資料不在快取中,則應用程式會如往常般從資料庫擷取它。 不過,它會
接著將資料儲存在快取中,以供後續要求使用。 下次當任何使用者要求該資料
時,則會直接從快取傳回它。
當你實作cache-aside模式時,會引進一個小問題。 由於你的資料現在儲存於
快取和資料存放區中,因此當你嘗試進行更新時,可能會遇到問題。 例如,若要
更新你的資料,你必須同時更新快取和資料存放區。
若要解決此問題,使用cache-aside模式讓快取中的資料失效。 當您更新應用
程式中的資料時,你應該先刪除快取中的資料,再直接對資料來源進行變更。
如此一來,下次要求資料時,快取中就不會有資料,而會重複此程序。
Lifetime:若要讓另行快取有效,請確定到期原則符合資料的存取頻率。
設定太短的到期時間,可能會造成應用程式持續從資料存放區擷取資料,並將它
新增至快取。
Evicting:快取相較於一般資料存放區有大小限制,因此必要時會收回資料
。 請務必為你的資料選擇適當的收回原則。
Priming:為了讓另行快取模式生效,許多解決方案會在快取中預先填入需要
經常存取的資料。
Consistency:實作另行快取模式並不保證資料存放區與快取之間的一致性
。 資料存放區中的資料可能會在未通知快取的情況下變更。 這可能會導致嚴重
的同步處理問題。
當你必須從使用磁碟的資料來源經常存取資料時,另行快取模式會很有用。 使用
另行快取模式,您會將重要的資料儲存在快取中,以協助加快擷取資料的速度。
手把手在Azure Cache for Redis建立transaction步驟
手把手練習 - 實作資料到期步驟
Day28教學講義:
https://docs.microsoft.com/zh-tw/learn/modules/work-with-mutable-and-partial-data-in-a-redis-cache/