因爲Azure Redis的性能在不一樣級別表現不一樣,當須要升級/縮放Redis的時候,從使用者的角度:html
從使用的步驟出發,升級的步驟爲:git
使用 Set-AzRedisCache 來縮放 Azure Redis 緩存實例,修改 Size、Sku 或 ShardCount 屬性github
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) 。
一、在縮放操做期間緩存名稱和密鑰不變,因此客戶端應用程序鏈接字符串不須要改變的。redis
二、標準和高級緩存在縮放操做期間保持可用,可是可能會出現鏈接故障,這些鏈接故障預期爲很小的故障,redis 客戶端應能當即從新創建鏈接,因此確保應用程序有重連機制。shell
三、若是高級版redis使用了虛擬網絡,那麼客戶端應用也須要在該虛擬網絡內才能夠訪問redis。數據庫
四、若是您爲高級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-clusteringc#
使用羣集功能時,是否須要對客戶端應用程序進行更改?
啓用羣集功能時,僅數據庫 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