在昨天我們談完如何使用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的
記憶體內部資料結構存放區。
今天早上操作Azure Redis Cache的SandBox(免費但有限制3小時)卡關,
晚上20:45再衝一波總算弄好
有些時候您必須保證可同時執行多個作業。 例如,在Onf 的即時訊息應用程式中
,使用者可以傳送:個別圖片、個別文字簡訊,或圖片和文字簡訊。 當使用者選擇
一起傳送圖片和文字簡訊時,您必須確定群組的其他成員能夠同時接收它們,因為
如果圖片和文字簡訊未一起接收,就有可能會在圖片和文字簡訊之間傳送個別訊息
。 這樣會讓整體對話令人感到困惑。
Redis 中的交易運作方式,是將多個要執行的命令以群組方式排入佇列。 當執行
交易時,在交易中排入佇列的命令保證會執行,而不會有來自其他用戶端的任何
其他命令交錯在其當中,若要開始交易區塊,請輸入 MULTI 命令。 後續的命令會
被排入佇列,而不會立刻執行。 執行 EXEC 命令會將所有已排入佇列的命令當作
交易單位來執行。 如果你決定要在命令正在排入佇列時中止開啟的交易,執行
DISCARD 命令將會關閉交易區塊,而不會執行「任何」已排入佇列的命令。
Redis 交易不支援復原的概念。 如果您使用不正確的語法將命令排入佇列至交易
區塊中,區塊將會維持開啟,但如果您嘗試以 EXEC 執行,將會自動捨棄該交易
區塊。 在交易「執行期間」(呼叫 EXEC 之後) 失的命令不會導致交易中止
或復原 — Redis 仍會執行所有命令,並將交易視為已成功完成。
從資料庫讀取資料通常是緩慢的程序。 這涉及到編譯複雜的查詢、準備查詢執行
計畫、執行查詢,然後準備結果。 在某些情況下,此程序也可能會從磁碟讀取
資料。 你可以在資料庫層級進行最佳化,例如預先編譯查詢,以及將部分資料
載入記憶體。 不過,從資料庫擷取資料時,一律會執行查詢及準備結果。
使用另行快取模式可解決這個問題。 在另行快取模式中,仍有應用程式和資料庫
,但現在也有快取,快取會將其資料儲存在記憶體中,因此不需要與檔案系統互動
,快取也會以非常簡單的資料結構(例如索引鍵值組)來儲存資料,因此不需要執行
複雜的查詢來收集資料,或在寫入資料時維護索引。 基於上述原因,快取的效能
一般會高於資料庫。 當您使用應用程式時,它會嘗試先從快取讀取資料。 如果
要求的資料不在快取中,則應用程式會如往常般從資料庫擷取它。 不過,它會
接著將資料儲存在快取中,以供後續要求使用。 下次當任何使用者要求該資料
時,則會直接從快取傳回它。
當你實作cache-aside模式時,會引進一個小問題。 由於你的資料現在儲存於
快取和資料存放區中,因此當你嘗試進行更新時,可能會遇到問題。 例如,若要
更新你的資料,你必須同時更新快取和資料存放區。
若要解決此問題,使用cache-aside模式讓快取中的資料失效。 當您更新應用
程式中的資料時,你應該先刪除快取中的資料,再直接對資料來源進行變更。
如此一來,下次要求資料時,快取中就不會有資料,而會重複此程序。
Lifetime:若要讓另行快取有效,請確定到期原則符合資料的存取頻率。
設定太短的到期時間,可能會造成應用程式持續從資料存放區擷取資料,並將它
新增至快取。
Evicting:快取相較於一般資料存放區有大小限制,因此必要時會收回資料
。 請務必為你的資料選擇適當的收回原則。
Priming:為了讓另行快取模式生效,許多解決方案會在快取中預先填入需要
經常存取的資料。
Consistency:實作另行快取模式並不保證資料存放區與快取之間的一致性
。 資料存放區中的資料可能會在未通知快取的情況下變更。 這可能會導致嚴重
的同步處理問題。
當你必須從使用磁碟的資料來源經常存取資料時,另行快取模式會很有用。 使用
另行快取模式,您會將重要的資料儲存在快取中,以協助加快擷取資料的速度。
手把手在Azure Cache for Redis建立transaction步驟
手把手實作Azure Redis Cache Data Expir步驟
Day28教學講義:
https://docs.microsoft.com/zh-tw/learn/modules/work-with-mutable-and-partial-data-in-a-redis-cache/