选择 Azure Managed Redis 的层级和套餐容量

在创建Azure托管 Redis 实例之前，请确定适合工作负荷的层并估算所需的容量。 本文将帮助你比较四个层、权衡内存与计算权衡，以及规划连接、保留内存、增长和缩放限制，仅使用可以提前收集的信息。 它不需要已部署的实例或Azure租户。

有关如何创建或调整缓存大小的说明，请参阅快速入门：创建Azure托管 Redis 实例并缩放Azure托管 Redis 实例。

比较这四个层级

Azure 托管 Redis 提供四个层级。 三个存储数据完全存储在内存中，其内存与 vCPU 比率不同。 第四种是“闪存优化”，可将数据跨内存和 NVMe 存储进行存储。 在查看特定 SKU 大小之前，请使用下表缩小选择范围。

有关按功能进行的完整功能比较，包括每个层的大小范围，请参阅 “选择正确的层”。 有关不同层级和大小的定价详情，请参阅Azure Managed Redis 定价页面。 确定稳定的区域、层级和基线节点数量后，请参阅 规划预留节省 以评估一年或三年的计算承诺。

内存与计算权衡

每个内存中层都会为 vCPU 和 Redis 分片交换内存容量。 内存优化为每个 GB 分配最少的 vCPU 和分片，计算优化分配最多，均衡位于两者之间。 更多的分片允许 Redis Enterprise 跨更多 vCPU 并行处理命令，从而增加吞吐量，并降低负载下的延迟。

当您不确定要缩放哪个维度时，请遵循以下通用准则：

• 如果 CPU 利用率或吞吐量是瓶颈，请移动到内存与 vCPU 比率较低的层（均衡或计算优化），而不是只增加内存大小。
• 如果内存容量是瓶颈，但性能是可接受的，则内存优化提供三个内存中层的最大内存与 vCPU 比率。
• 在同一层级内增大实例规格也会增加 vCPU 和分片，但对于计算密集型工作负载，与其仅靠增大实例规格，通常切换到更偏重计算的层级会更有效。

随着Azure托管 Redis 优化性能，每个 SKU 的 vCPU 和分片的确切数目可能会随时间变化，因此不要将任何特定比率视为固定的。 有关不同样本大小下的示例比例以及分片行为的更多详细信息，请参阅 分片配置。 有关测量给定层和大小的吞吐量和延迟的指导，请参阅使用 Azure 托管 Redis 进行性能测试。

闪存优化：热数据和冷数据注意事项

在闪存优化实例上，大约 20% 缓存空间位于 RAM 上，其余 80% 使用 NVMe 闪存存储。 所有密钥名称始终存储在 RAM 中，而值基于访问频率在 RAM（“hot”）和闪存（“冷”）之间移动，并且数据必须在读取或写入之前移动到 RAM。 由于实例会先占满可用的 RAM，然后才使用闪存存储，因此轻负载的测试实例的延迟可能优于满负载的生产实例，因为随着使用量的增加，能够装入 RAM 的数据占比会越来越小。

这些特征会影响层选择：Flash Optimized 不支持活动异地复制、非聚集实例、RediSearch（包括矢量搜索）、RedisBloom 或 RedisTimeSeries — RedisJSON 是唯一受支持的模块。 如果要评估此层的值大小，则其记录的指南建议将单个值保持在 512 KB 以下。 有关详细的工作负荷指南和最佳做法，请参阅 Flash 优化层的最佳做法。

连接限制和余量

每个 SKU 具有最大数量的客户端连接，并且限制会随着更高的性能层和更大的大小而增加。 请提前估算预期的峰值连接数，因为即使内存和 CPU 仍有余量，这一限制也可能迫使您升级到更大的规格或更高的层级。 有关按层和大小的当前权威连接限制数字，请参阅 最大客户端连接数。 其中列出的一些较大 SKU 目前处于预览阶段；请参阅本文后面的 预览 SKU 资格要求。

保留的内存

在每个Azure托管 Redis 实例上，大约 20% 可用内存保留为非缓存操作的缓冲区，例如故障转移期间复制和活动异地复制缓冲区。 此缓冲区有助于提高缓存性能，并防止内存不足。 据此规划可用容量，并确认在你正在考虑的 SKU 上可为你的数据集提供的有效内存容量，而不要假设其标称的完整容量都可用于存放数据。 有关详细信息，请参阅 保留内存。

此保留内存缓冲区与高可用性（HA）影响 已用内存 指标的方式不同。 启用 HA 后，该指标报告主分片和副本分片使用的内存，其大小可能大致是实际数据集大小的两倍，但 SKU 的内存限制已经考虑到了此复制，因此，请根据实际数据集大小选择 SKU，而不是将其加倍来补偿副本。 监控已用内存百分比指标，该指标已按 SKU 限制进行了归一化处理，并计划在该百分比持续高于 75% 之前进行扩展。 有关详细信息，请参阅 容量规划的估计内存。

数据集大小和增长空间

确定实例大小时，不仅要考虑值的原始大小：

• 每个密钥开销：每个密钥都携带内部元数据（指针、类型信息、过期跟踪），通常每个密钥 50 到 100 个字节，具体取决于密钥名称长度和值类型。 对于具有大量小密钥的工作负荷，此开销会增加。
• 密钥名称：密钥名称越长，可大规模增加内存使用量。
• 过期跟踪：具有 TTL 的密钥使用额外的内存进行过期记帐。
• 随时间的增长：规划初始容量以包括预期数据增长的余地，而不仅仅是当前的数据集大小。

对于 Azure 托管 Redis 而言，扩展余量比某些其他数据存储更重要，因为文档明确说明了缩容存在限制：要减少内存，当前使用量必须已经低于目标容量，而且你只能根据 vCPU 和分片配置，缩容到部分兼容的 SKU。 请查看Azure 托管 Redis 的缩放限制，以免初始容量选择依赖于后续还能缩小实例。

模块和索引开销

创建实例时，必须启用模块（RediSearch、RedisBloom、RedisTimeSeries 和 RedisJSON）。 之后无法添加或更新模块。 在预配之前规划模块要求，因为稍后进行更改意味着重新创建缓存。 RediSearch、RedisBloom 和 RedisTimeSeries 在 Flash Optimized 上不可用;只有 RedisJSON 是。 只有 RediSearch 和 RedisJSON 支持活动异地复制。 有关跨所有层的权威当前模块支持矩阵，请参阅 Redis 模块的范围。

如果使用 RediSearch，则必须使用企业群集策略和 NoEviction 逐出策略。 在使用 NoEviction 时，当内存耗尽时，Redis 不会逐出键，而是会在写入时返回错误，因此，与依赖逐出机制来管理容量的工作负载相比，建立了搜索索引的工作负载需要额外的内存余量。 搜索索引和其他模块的数据结构除了其所表示的原始键/值数据本身外，还会消耗额外的内存，因此在估算容量时，也要将这部分开销计算在内，尽管其具体开销取决于您的模式和数据。 有关群集策略权衡，请参阅 群集策略。

高可用性和副本影响

建议在所有生产场景中使用高可用性（HA）；若要获得 Azure 托管 Redis SLA 的保障，则必须启用高可用性。 可以在预配实例时选择 HA，也可以在尚未启用 HA 的实例上后续启用它；但不能在已启用 HA 的实例上将其禁用。 启用 HA 后，实例会部署为主分片和副本分片分布在至少两个节点上；在支持可用区的区域中，节点默认分布在各可用区之间。 在没有 HA 的情况下预配的实例没有 SLA 覆盖范围，并且可能会在维护期间遇到数据丢失和停机或意外故障，因此请保留用于开发和测试方案的配置。

如果您计划使用主动异地复制，请注意，Balanced B0 和 B1 SKU 不支持此功能。 有关详细信息，请参阅 高可用性 和 活动异地复制。

预览版 SKU 资质

所有四个层中的某些大小都处于公共预览状态：内存优化、均衡和计算优化大小超过 350 GB（480 GB 及更大），闪存优化大小为 1,920 GB 和 4,500 GB。 异地复制缓存的扩展目前也处于预览阶段。

在规划预览版大小的生产能力之前，请确认该大小在目标区域中可用，并查看Microsoft Azure预览版补充使用条款，因为预览功能和可用性可能会更改。 请通过自行测试来验证针对预览 SKU 的任何容量假设，而不要仅仅依赖文档中给出的范围；此外，在部署前也要定期重新审视你的计划，以防预览状态或规格可用性发生变化。

将限制因素纳入计划

由于某些扩展路径受到限制，因此预先选择合适的层级和大小，可以降低日后需要进行造成中断的迁移的风险：

• 不能在闪存优化层级与任何内存层级（内存优化、均衡或计算优化）之间进行扩缩容，反之亦然。 选择错误的层系列意味着重新创建缓存。
• 减少内存大小要求当前内存使用量已低于目标大小，并且只能缩减到具有兼容 vCPU 和分片配置的 SKU。
• 缩放可以更改实例的基础 IP 地址。 如果在防火墙规则、网络安全组或客户端配置中对 IP 地址进行硬编码，而不是使用 DNS 名称，请规划这种可能性。
• 如果使用活动异地复制，异地复制组中的所有实例都必须使用相同的缓存大小，因此缩放一个实例通常需要协调整个组的缩放。
• 群集策略（OSS、企业或非群集）是在创建时设置的，通常以后无法更改，除非非群集缓存以后可以移动到群集策略。 非群集配置仅适用于大小为 25 GB 或更小的缓存。 在预配之前决定群集策略，因为它也会影响可以使用的模块和功能。

有关完整详细信息，请参阅Azure托管 Redis 的缩放限制。

预预配工作表

在预配 Azure 托管 Redis 实例之前，请回答这些问题。 每行指向具有更多详细信息的部分或文章。

相关内容

• 计划预留节省
• 缩放 Azure 托管 Redis 实例
• Azure 托管 Redis 体系结构
• 闪存优化层的最佳做法
• 内存管理的最佳做法