Azure 托管 Redis 体系结构

Azure 托管 Redis 在 Redis 企业 堆栈上运行，它比 Redis 社区版具有显著优势。 以下信息更详细地说明了如何构建 Azure 托管 Redis，包括对高级用户有用的信息。

与 Azure Cache for Redis 的比较

Azure Redis 缓存的基本层、标准层和高级层在 Redis 社区版上运行。 此 Redis 社区版具有几个重大限制，包括单线程。 此限制可显著降低性能，并降低缩放效率，因为服务不会充分利用更多的 vCPU。 典型的 Azure Cache for Redis 实例使用如下体系结构：

请注意，使用两个 VM - 一个主 VM 和一个副本。 这些 VM 也称为节点。 主节点运行主 Redis 进程并接受所有写入。 复制以异步方式执行到副本节点，以在维护、缩放或意外故障期间提供备份副本。 由于社区 Redis 的单线程设计，每个节点只能运行单个 Redis 服务器进程。

Azure 托管 Redis 的体系结构改进

Azure 托管 Redis 使用更高级的体系结构，如下所示：

有几个区别：

• 每个虚拟机（或节点）并行运行多个 Redis 服务器进程（称为分片）。 多个分片可让系统可更高效地利用每个虚拟机上的 vCPU 并提高性能。
• 并非所有主要 Redis 分片都位于同一 VM/节点上。 相反，主分片和副本分片分布在这两种节点之间。 由于主分片使用比副本分片更多的 CPU 资源，因此此方法使更多的主分片可以并行运行。
• 每个节点都有一个高性能代理进程来管理分片、处理连接管理并触发自我修复。

此体系结构可实现更高的性能和高级功能，例如 活动异地复制。

集群

每个 Azure 托管的 Redis 实例都在内部配置为在所有层级和 SKU 上使用集群。 Azure 托管 Redis 基于 Redis Enterprise，每个节点可以使用多个分片。 此功能包括仅设置为使用单个分片的较小实例。 聚类分析是跨多个 Redis 进程（也称为分片）划分 Redis 实例中的数据的一种方法。 Azure 托管 Redis 提供三个 群集策略 ，用于确定哪些协议可供 Redis 客户端连接到缓存实例。

群集策略

Azure 托管的 Redis 提供三个聚类分析策略：OSS、企业和非群集。 OSS 群集策略适用于大多数应用程序，因为它支持更高的最大吞吐量，但每个版本都有自己的优点和缺点。

• 如果要从基本、标准或高级非聚集拓扑移动，请考虑使用 OSS 群集来提高性能。 仅当应用程序不支持 OSS 或企业拓扑时，才使用非聚集配置。 OSS 群集策略实现与 Redis 开源软件相同的 API。 Redis 群集 API 允许 Redis 客户端直接连接到每个 Redis 节点上的分片，最大限度地减少延迟并优化网络吞吐量。 随着分片数量和 vCPU 的数量增加，吞吐量几乎呈线性缩放。 OSS 群集策略通常提供最低的延迟和最佳吞吐量性能。 但是，OSS 群集策略要求客户端库支持 Redis 群集 API。 目前，几乎所有 Redis 客户端都支持 Redis 群集 API，但较旧客户端版本或专用库可能存在兼容性问题。

不能将 OSS 群集策略用于 RediSearch 模块。

OSS 群集协议要求客户端建立正确的分片连接。 初始连接是通过端口 10000 建立的。 连接到单个节点时使用 85XX 范围内的端口。 85xx 端口可能会随时间而变化，不应将其硬编码到应用程序中。 支持群集的 Redis 客户端使用 CLUSTER NODES 命令来确定用于主分片和副本分片的确切端口，并为你建立分片连接。

企业群集策略是一种更简单的配置，它对所有客户端连接使用单个终结点。 使用企业群集策略时，它会将所有请求路由到充当代理的单个 Redis 节点。 此节点在内部将请求路由到群集中的正确节点。 这种方法的优点是，它使 Azure 托管的 Redis 在用户看来不是群集。 这意味着 Redis 客户端库不需要支持 Redis 群集，才能获得 Redis Enterprise 的某些性能优势。 使用单个终结点可以提高向后兼容性，并使连接更简单。 缺点是，单节点代理可能是计算利用率或网络吞吐量的瓶颈。

企业群集策略是可用于 RediSearch 模块的唯一策略。 虽然企业群集策略使 Azure 托管 Redis 实例在用户看来是不分群集的，但它仍然对多密钥命令有一些限制。

“非群集”聚类分析策略在每个节点上存储数据，但不进行分片。 它仅适用于大小为 25 GB 且更小的缓存。 使用非聚集群集策略的方案包括：

• 从非分片的 Redis 环境迁移时。 例如，Azure Cache for Redis 的基本、标准和高级 SKU 的非分片拓扑。
• 在广泛运行跨槽命令并将数据划分为分片时，将导致故障。 例如，MULTI 命令。
• 使用 Redis 作为消息中转站时，不需要分片。

使用非聚集策略的注意事项包括：

• 此策略仅适用于小于或等于 25 GB 的 Azure 托管 Redis 层。
• 它不像其他群集策略那样高性能，因为当缓存分片时，CPU 只能与 Redis Enterprise 软件进行多线程处理。
• 若要纵向扩展 Azure 托管 Redis 缓存，必须先更改群集策略。
• 如果要从基本、标准或高级非聚集拓扑移动，请考虑使用 OSS 群集来提高性能。 仅当应用程序不支持 OSS 或企业拓扑时，才使用非聚集配置。

横向扩展或添加节点

核心 Redis Enterprise 软件通过使用更大的 VM 进行扩展，或者通过添加更多节点或 VM 进行横向扩展。 这两种缩放选项都增加了更多的内存、更多的 vCPU 和更多的分片。 由于这种冗余，Azure 托管 Redis 无法控制每个配置中使用的特定节点数。 此实现详细信息是抽象的，以避免混淆、复杂性和欠佳配置。 相反，每个 SKU 都设计了一个可最大化 vCPU 和内存的节点配置。 Azure 托管 Redis 的某些 SKU 使用两个节点，而另一些则使用更多节点。

多键命令

由于 Azure 托管 Redis 实例使用群集配置，因此可能会在对多个密钥进行作的命令上看到 CROSSSLOT 异常。 行为因使用的群集策略而异。 如果使用 OSS 群集策略，多键命令中的所有密钥都必须映射到 相同的哈希槽。

你可能还会看到 Enterprise 群集策略的 CROSSSLOT 错误。 只有以下多键命令允许在启用了企业集群的槽位之间使用：DEL、MSET、MGET、EXISTS、UNLINK和TOUCH。

在 Active-Active 数据库中，多键写入命令（DEL，）MSETUNLINK只能在位于同一槽的键上运行。 但是，允许在 Active-Active 数据库的不同槽之间使用以下多键命令：MGET、EXISTS和TOUCH。 有关更多信息，请参阅数据库群集。

分片配置

Azure 托管 Redis 的每个 SKU 并行运行特定数量的 Redis 服务器进程，称为 分片。 吞吐量性能、分片数和每个实例上可用的 vCPU 数之间的关系很复杂。 无法手动更改分片数。

对于给定的内存大小，内存优化版本具有最少的 vCPU 和分片数，而计算优化版本具有最高的版本。

增加分片的数量通常会提高性能，因为Redis操作可以并行运行。 但是，如果没有 vCPU 可用于执行命令，性能可能会下降。

对分片进行映射以优化每个 vCPU 的使用，同时为 Redis 服务器进程、管理代理和操作系统任务预留 vCPU 周期，这些任务也会影响性能。 创建的客户端应用程序与 Azure 托管 Redis 交互，就像它是单个逻辑数据库一样。 服务处理跨 vCPU 和分片的路由。

要增加 SKU 中的分片数，请使用该 SKU 中的较高层级。 还可以更改 SKU 以满足性能需求。

下表展示了在特定层级规模下，vCPU 与主要分片的比率。 列中的数据并不代表 vCPU 或分片数量的保证。 这些表仅用于说明。

注释

Azure 托管 Redis 通过调整每个 SKU 上的分片和 vCPU 数量来持续优化性能。

内存优化、均衡和计算优化版本

下表显示了 大小 与 vCPU/主分片的关系的一般示例。

等级	内存优化	均衡	计算优化
大小(GB)	vCPU/主分片	vCPU/主分片	vCPU/主分片
24 ¹	4/2	8月6日	12月16日
60 ¹	8月6日	12月16日	32/24

¹ 在特定层级大小下的 vCPU 与主分片的比率并不构成对 SKU 或层级的保证。

闪存优化版本

下表显示了 大小 与 vCPU/主分片的关系的一般示例。

等级	Flash Optimized （预览版）
大小(GB)	vCPU/主分片
480 ¹ ²	12月16日
720 ¹ ²	24/24

¹ 这些层级目前处于公共预览阶段。

² 在特定层级大小下，vCPU 与主分片的比例并不代表该 SKU 或层级的性能保证。

重要

使用超过 235 GB 存储的所有内存中层都处于公共预览状态，包括内存优化 M350 及更高版本;平衡 B350 及更高版本;和计算优化 X350 及更高版本。 所有这些层及更高版本均以公共预览版提供。

所有闪存优化层均以公共预览版提供。

在未启用高可用性模式的情况下运行

可以在未启用高可用性（HA）模式的情况下运行。 此配置意味着 Redis 实例未启用复制，并且无权访问可用性 SLA。 不要在开发和测试方案之外以非 HA 模式运行。 不能在已创建的实例中禁用高可用性。 可以在没有高可用性的实例中启用高可用性。 由于在没有高可用性的情况下运行的实例使用较少的 VM 和节点，因此 vCPU 不会高效使用，因此性能可能会降低。

保留的内存

在每个 Azure 托管 Redis 实例上，大约 20% 的可用内存被保留用于非缓存任务的缓冲，例如故障转移期间的复制和活动地理复制缓冲区。 此缓冲区有助于提高缓存性能，并防止内存不足。

缩小规模

目前 Azure 托管 Redis 不支持缩减规模。 有关详细信息，请参阅 缩放 Azure 托管 Redis 的限制。

闪存优化层

闪存优化层既使用 NVMe Flash 存储，又使用 RAM。 由于 Flash 存储成本更低，因此使用闪存优化层让你能够为了性价比牺牲一些性能。

在闪存优化实例上，20% 的缓存空间位于 RAM 上，其他 80% 则使用 Flash 存储。 所有密钥都存储在 RAM 上，而值可以存储在 Flash 存储或 RAM 中。 Redis 软件会智能地确定值的位置。 经常访问的热值存储在 RAM 上，而不太常用的冷值则保存在 Flash 上。 在读取或写入数据之前，必须将其移动到 RAM，成为热数据。

由于 Redis 将进行优化以实现最佳性能，因此在向 Flash 存储添加项之前，该实例将首先填满可用的 RAM。 先填充 RAM 会对性能产生一些影响：

• 在按低内存使用率进行测试时，可能会出现更好的性能和较低的延迟。 在内存使用率较低的测试阶段，使用完整缓存实例进行测试可能会降低性能，因为此阶段仅依赖于 RAM。
• 向缓存写入更多数据时，与 Flash 存储相比，RAM 中的数据比例会降低，这通常也会降低延迟和吞吐量性能。

适用于闪存优化层的工作负载

在闪存优化层上运行良好的工作负荷通常具有以下特征：

• 读取密集型，其读取命令与写入命令的比率较高。
• 访问侧重于使用频率远高于数据集中其他部分的一组键。
• 与键名称相比，值相对较大。 （由于键名始终存储在 RAM 中，因此较大的值可能会成为内存增长的瓶颈。）

不适合闪存优化层的工作负载

某些工作负载的访问特征不太适合用于闪存优化层的设计。

• 写入密集型工作负载。
• 大多数数据集中的随机或统一数据访问模式。
• 键名称较长，但值的大小相对较小。

相关内容

• 缩放 Azure 托管 Redis 实例