問題描述
由於Azure Redis的效能在不同級別表現不同，當需要升級/縮放Redis的時候，從使用者的角度：
- 需要知道有那些步驟？
- 注意事項？
- 潛在影響？
- 停機事件視窗?
- 升級預估時間？
解決方案
從使用的步驟出發，升級的步驟為：
1）Azure門戶頁面操作
- 選擇縮放(Scale)目錄
- 選擇需要的級別(C1 ~ C6, P1 ~P5)
- 點選Select按鈕確認
2）使用Powershell命令
使用 Set-AzRedisCache 來縮放 Azure Redis 快取例項,修改 Size、Sku 或 ShardCount 屬性
Set-AzRedisCache [-ResourceGroupName <String>] -Name <String> [-Size <String>] [-Sku <String>] [-RedisConfiguration <Hashtable>] [-EnableNonSslPort <Boolean>] [-TenantSettings <Hashtable>] [-ShardCount <Int32>] [-MinimumTlsVersion <String>] [-Tag <Hashtable>] [-DefaultProfile <IAzureContextContainer>] [-WhatIf] [-Confirm] [<CommonParameters>]
=====================================================
縮放 Azure Redis 快取: https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-manage-redis-cache-powershell#to-scale-an-azure-cache-for-redis
Set-AzRedisCache：https://docs.microsoft.com/zh-cn/powershell/module/az.rediscache/set-azrediscache?view=azps-5.1.0
升級/縮放限制：
- 不能從較高的定價層縮放到較低的定價層。
- 不能從 高階 快取向下縮放到 標準 或 基本 快取。
- 不能從 標準 快取向下縮放到 基本 快取。
- 可從 基本 快取縮放到 標準 快取，但不能同時更改大小。 如果需要不同大小，則可以執行後續縮放操作以縮放為所需大小。
- 不能從 基本 快取直接縮放到 高階 快取。 必須在一個縮放操作中從 基本 縮放到 標準 ，並在後續的縮放操作中從 標準 縮放到 高階 。
- 不能從較大的大小減小為 C0 (250 MB) 。
注意事項：
1、在縮放操作期間快取名稱和金鑰不變，所以客戶端應用程式連線字串不需要改變的。
2、標準和高階快取在縮放操作期間保持可用，但是可能會出現連線故障，這些連線故障預期為很小的故障，redis 客戶端應能立即重新建立連線，所以確保應用程式有重連機制。
3、如果高階版redis使用了虛擬網路，那麼客戶端應用也需要在該虛擬網路內才可以訪問redis。
4、如果您為高階redis開啟了群集功能的話，那麼客戶端也需要對應改動，詳細請參考：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-premium-clustering#do-i-need-to-make-any-changes-to-my-client-application-to-use-clustering
使用群集功能時，是否需要對客戶端應用程式進行更改？
啟用群集功能時，僅資料庫 0 可用。 如果客戶端應用程式使用多個資料庫並嘗試讀取或寫入資料庫 0 之外的其他資料庫，則會引發以下異常。
Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6有關詳細資訊，請參閱 Redis 群集規範 - 已實現子集。
如果使用的是 StackExchange.Redis，則必須使用 1.0.481 或更高版本。 連線到該快取時，可以使用的終結點、埠和金鑰與連線到未啟用群集功能的快取時使用的相同。 唯一的區別是，所有讀取和寫入都必須在資料庫 0 中進行。
其他客戶端可能有不同的要求。 請參閱 是否所有 Redis 客戶端都支援群集功能？
如果應用程式使用的多個金鑰操作都在單個命令中成批執行，則所有金鑰都必須位於同一分片。 若要查詢同一分片中的金鑰，請參閱金鑰在群集中是如何分佈的？
如果使用的是 Redis ASP.NET 會話狀態提供程式，則必須使用 2.0.1 或更高版本。 請參閱 能否在 Redis ASP.NET 會話狀態和輸出快取提供程式中使用群集功能？
升級時間：
縮放時間取決於快取中的資料量，資料量越大，完成縮放所需的時間就越長。 縮放大約需要 20 分鐘。
潛在影響：
標準和高階快取在縮放操作期間保持可用，但是可能會出現連線故障，這些連線故障預期為很小的故障，redis 客戶端應能立即重新建立連線。
故障轉移如何影響我的客戶端應用程式？
客戶端應用程式遇到的錯誤數目取決於故障轉移時該連線上掛起的運算元目。 通過關閉連線的節點路由的任何連線將遇到錯誤。 在連線中斷時，許多客戶端庫可能會引發不同型別的錯誤，包括超時異常、連線異常或套接字異常。 異常的數目和型別取決於當快取關閉其連線時，請求在程式碼路徑中所處的位置。 例如，在發生故障轉移時傳送了請求但未收到響應的操作可能會收到超時異常。 對關閉的連線物件發出的新請求將收到連線異常，直到重新連線成功為止。
大多數客戶端庫會嘗試重新連線到快取（如果採用此配置）。 但是，不可預測的 bug 偶爾會將庫物件置於不可恢復狀態。 如果出錯的持續時間超過了預先配置的時間，則應重新建立連線物件。 在 Microsoft.NET 和其他物件導向的語言中，可以使用 Lazy<T> 模式來重新建立連線，而無需重啟應用程式。
重複使用連線。 建立新連線是高開銷的操作，會增大延遲，因此請儘量重複使用連線。 如果你選擇建立新連線，請確保在釋放舊連線之前先將其關閉（即使是在 .NET 或 Java 等託管記憶體語言中）。
將客戶端庫配置為使用至少 15 秒的連線超時 ，以便即使是在 CPU 負載較高的情況下，系統也有時間建立連線。 使用較小的連線超時值無法保證在該時間範圍內能夠建立連線。 如果出現問題（客戶端 CPU 負載偏高、伺服器 CPU 負載偏高等），則使用較短的連線超時值會導致連線嘗試失敗。 此行為通常會使問題變得更糟。 使用較短的超時不僅無助於解決問題，而且會加劇問題，這會強制系統重啟嘗試重新連線的程式，從而可能導致出現“連線 -> 失敗 -> 重試”迴圈。 我們通常建議將連線超時保留為 15 秒或更長。 讓連線嘗試在 15 或 20 秒後成功，比失敗後立即重試更有利。 與最初讓系統花費更長時間嘗試連線相比，這種重試迴圈可能會導致服務中斷的持續時間變長。
效能變化：
每個級別的效能資料(連線數，RPS, 記憶體，CPU）變化如下：
基本快取和標準快取
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
高階快取
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
【Azure Redis 快取 Azure Cache For Redis】使用Redis自帶redis-benchmark.exe命令測試Azure Redis的效能
參考資料：
縮放redis：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-configure#scale
縮放redis的注意事項：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-scale#scaling-faq
排查客戶端問題：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-troubleshoot-client#client-side-bandwidth-limitation
配置虛擬網路的redis：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-premium-vnet