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