繼承上一次討論了Azure Redis的可用性，可靠性，穩定性，安全性，監控方面的九大功能點。詳情可回顧文章：【Azure Redis 快取】Azure Redis功能性討論
這次我們繼續討論Azure Redis的以下六點問題：
1：Redis能否暫停或重啟
2：Redis群集擴大分片後能否縮小
3：Redis預設是否會備份，基礎和標準版本如何備份資料？
4：RDB 暫留和AOF 暫留有什麼區別
5：設定計劃更新後，更新開始前後，redis是否可以繼續使用
6：異地複製
一：Redis能否暫停或重啟
可以重啟，但是不能暫停。除基本定價層的Redis外，其他都是有主/從(副本)兩個節點，如果只重新啟動其中一個節點，資料通常不會丟失，但仍然存在丟失的可能。重啟的操作會根據重啟的節點不同對已連線的客戶端有不同的影響：
- 主 - 重新啟動主節點時，Redis 會發生故障轉移到副本節點，並將其提升為主節點。 在此故障轉移期間，可能會有一個較短的時間間隔無法連線到Redis。
- 副本 - 重新啟動副本節點時，通常不會影響快取客戶端。
- 主和副本 - 同時重新啟動這兩個快取節點時，快取中的所有資料都會丟失，並且無法連線到快取，直到主節點重新聯機。 如果已配置資料永續性，則在快取重新聯機時會還原最新備份，但在最新備份後發生的所有快取寫入都將丟失。
- 已啟用群集的高階快取的節點 - 重新啟動已啟用群集的高階快取的一個或多個節點時，所選節點的行為與重新啟動非群集快取的相應節點時相同。
更多的重啟問題，可參考官方文件：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-administration#reboot
二：Redis群集擴大分片後能否縮小
可以的，可以在Redis的門戶頁面中進行分片大小的縮放及擴充套件。
更多關於Redis叢集問題，請參考官方文件：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-premium-clustering#what-is-redis-cluster
三：Redis預設是否會備份，基礎和標準版本如何備份資料？
Redis不會預設備份，並且基礎版，標準版並不具備備份(RDB, AOF)的功能。 Redis的資料暫留只在高階版中提供，它提供兩種方式進行資料備份 RDB暫留和AOF暫留。
- RDB 暫留 - Azure Redis 快取按照可配置的備份頻率(預設60分鐘)，將 Azure Redis 快取的快照以 Redis 二進位制格式暫留在儲存賬號中(Blob)上。
- AOF 暫留 - 追加檔案，Azure Redis 快取將每個寫入操作儲存到日誌，此日誌每秒至少儲存到 Microsoft Azure 儲存帳戶一次。
更多資料持久化資訊，請參考官方文件：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-premium-persistence#what-is-data-persistence
四：RDB 暫留和AOF 暫留有什麼區別
AOF 暫留將每個寫入儲存到日誌，與 RDB 暫留相比，這對吞吐量有一些影響，因為 RDB 暫留基於配置的備份間隔儲存備份，對效能產生的影響非常小。
如果主要目標是最大程度減少資料損失，並且可應付快取吞吐量下降，請選擇 AOF 暫留。 如果希望在快取上保持最優吞吐量，但仍希望使用一種資料恢復機制，請選擇 RDB 暫留。
注：AOF 暫留對效能的影響：
當快取低於最大負載（CPU 和伺服器負載皆低於 90%）時，AOF 暫留對吞吐量產生約 15% - 20% 的影響。 快取處於這些限制以內時不存在延遲問題。 但是，啟用 AOF 時快取將更快達到這些限制。
關於Redis資料暫留的優缺點，可參考官方網站：https://redis.io/topics/persistence#rdb-advantages
五：設定計劃更新後，更新開始前後，redis是否可以繼續使用
正常情況下，如果Redis是標準版或者高階版，Redis在更新時是可用的。
因為基本版快取沒有多個節點，僅建議用於開發和測試目的。在更新完成之前不可用。
Redis 服務定期使用最新的平臺功能和修補程式更新快取。 該服務遵循以下步驟來修補快取
- 管理服務選擇一個要修補的節點。
- 如果所選的節點是主節點，則相應的副本節點將以協作方式提升自身。 這種升級被視為計劃性故障轉移。
- 所選節點將重新啟動以獲取新的更改，然後以副本節點的角色重新啟動。
- 副本節點連線到主節點並同步資料。
- 資料同步完成後，將對剩餘的節點重複修補過程。
因為修補屬於計劃性故障轉移，所以副本節點會快速將自身提升為主節點，並開始為請求和新連線提供服務。 群集快取的每個分片單獨進行修補，不會關閉與另一個分片的連線。
更多資訊，請參考官方文件：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-failover
六：異地複製
異地複製設計為災難恢復解決方案。是一種用於連結兩個高階層 Azure Redis 快取例項的機制。 預設情況下，應用程式將寫入主要區域並從中進行讀取。
異地複製先決條件
若要在兩個快取之間配置異地複製，必須滿足以下先決條件：
- 這兩個快取是高階層快取。
- 這兩個快取在同一 Azure 訂閱中。
- 輔助連結快取的大小等於或大於主連結快取的大小。
- 這兩個快取都已建立且處於執行狀態。
異地複製不支援某些功能：
- 異地複製不支援永續性。
- 如果這兩個快取都啟用了群集功能並且具有相同數目的分片，則支援群集。
- 支援同一 VNET 中的快取。
- 也支援不同 VNET 中的快取，但需要注意一些問題。 有關詳細資訊，請參閱當快取位於 VNET 中時是否可以使用異地複製？。
完成異地複製配置後，連結快取對會有以下限制：
- 輔助連結快取為只讀狀態；這意味著只能從中讀取，但不能向其寫入任何資料。
- 新增連結前輔助連結快取中的任何資料都會被刪除。 但如果以後刪除了異地複製，複製的資料則會保留在輔助連結快取中。
- 連結快取時無法縮放任一快取。
- 如果快取已啟用群集功能，則無法更改分片數目。
- 無法在任一快取上啟用暫存。
- 可以從任一快取匯出。
- 無法匯入到輔助連結快取。
- 只有在取消連結快取之後，才可以刪除任一連結快取或包含它們的資源組。 有關詳細資訊，請參閱嘗試刪除連結快取時為何操作會失敗？
- 如果快取位於不同的區域，網路傳出費用將適用於在區域之間移動的資料。 有關詳細資訊，請參閱跨 Azure 區域複製資料的費用是多少？
- 主要和輔助連結快取之間不會發生自動故障轉移。 有關如何故障轉移客戶端應用程式的詳細資訊，請參閱如何故障轉移到輔助連結快取？
關於異地複製，可以參考官方文件：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-geo-replication