【Azure Redis 缓存 Azure Cache For Redis】Azure Redis由低级别(C)升级到高级别(P)的步骤和注意事项, 及对用户现有应用的潜在影响，是否须要停机时间窗口，

问题描述

因为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) 。

 

注意事项：

一、在缩放操做期间缓存名称和密钥不变，因此客户端应用程序链接字符串不须要改变的。

二、标准和高级缓存在缩放操做期间保持可用，可是可能会出现链接故障，这些链接故障预期为很小的故障，redis 客户端应能当即从新创建链接，因此确保应用程序有重连机制。

三、若是高级版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-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）变化以下：

基本缓存和标准缓存 C0 (250 MB) 缓存 - 最多支持 256 个链接 C1 (1 GB) 缓存 - 最多支持 1,000 个链接 C2 (2.5 GB) 缓存 - 最多支持 2,000 个链接 C3 (6 GB) 缓存 - 最多支持 5,000 个链接 C4 (13 GB) 缓存 - 最多支持 10,000 个链接 C5 (26 GB) 缓存 - 最多支持 15,000 个链接 C6 (53 GB) 缓存 - 最多支持 20,000 个链接

高级缓存 P1 (6 GB - 60 GB) - 最多支持 7,500 个链接 P2 (13 GB - 130 GB) - 最多支持 15,000 个链接 P3 (26 GB - 260 GB) - 最多支持 30,000 个链接 P4 (53 GB - 530 GB) - 最多支持 40,000 个链接

标准缓存大小     兆位/秒（Mb/秒）/兆字节/秒（MB/秒） 非 SSL 请求数/秒 (RPS) SSL 请求数/秒 (RPS) C0 250 MB 共享 100/12.5 15,000 7,500 C1 1 GB 1 500/62.5 38,000 20,720 C2 2.5 GB 2 500/62.5 41,000 37,000 C3 6 GB 4 1000/125 100,000 90,000 C4 13 GB 2 500/62.5 60,000 55,000 C5 26 GB 4 1,000 / 125 102,000 93,000 C6 53 GB 8 2,000 / 250 126,000 120,000 订价层 大小 CPU 核心数 可用带宽 1 KB 值大小 1 KB 值大小

高级缓存大小   每一个分片的 CPU 核心数 兆位/秒（Mb/秒）/兆字节/秒（MB/秒） 每分片非 SSL 请求数/秒 (RPS) 每分片 SSL 请求数/秒 (RPS) P1 6 GB 2 1,500 / 187.5 180,000 172,000 P2 13 GB 4 3,000 / 375 350,000 341,000 P3 26 GB 4 3,000 / 375 350,000 341,000 P4 53 GB 8 6,000 / 750 400,000 373,000 P5 120 GB 20 6,000 / 750 400,000 373,000

 

【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