【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) 。
注意事项：
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
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!
