Azure托管 Redis 使用 Redis 企业体系结构，该体系结构可以跨节点并行运行多个 Redis 服务器进程（称为分片）。 分片允许服务同时使用更多 vCPU，在节点之间分配主分片和副本分片，并随着缓存容量的增长增加吞吐量。 此设计还支持自我修复和活动异地复制等功能。
此体系结构从Azure Cache for Redis的基本层、标准层和高级层转变。 这些层使用 Redis 社区版，通常在每个节点上运行一个单线程 Redis 服务器进程。 通过使用Azure托管 Redis，群集和并行分片执行是默认体系结构的一部分，而不是可选的横向扩展功能。 较小的 Azure Managed Redis 实例可能只使用一个分片，而非集群策略以非分片方式存储数据，但所有实例都使用 Redis Enterprise 节点架构。
选择缓存向客户端公开的群集策略： OSS、 企业或 非群集。 该策略不会选择所使用的底层 Redis 实现。 而是确定客户端是直接连接到分片、通过托管代理连接还是使用未分片配置。 此选项会影响客户端配置、支持的命令、性能以及以后是否可以更改策略。 预配缓存时选择策略，因此请在创建实例之前做出决策。
本文比较概念级别的三个策略。 它不建议针对特定工作负荷模式制定策略，并且不包括性能编号，因为实际吞吐量和延迟取决于 SKU、层和流量配置文件。
每个策略更改的内容
- OSS 群集策略 实现 Redis 群集 API。 支持群集 API 的客户端直接连接到保存其数据的分片，而不是通过中介。 客户端库负责在数据移动时发现分片位置和跟踪重定向。
- 企业群集策略 为所有客户端连接公开单个终结点。 缓存节点上的代理进程在内部将每个请求路由到正确的分片。 从客户端的角度来看，缓存看起来像单个非聚集服务器。
- 非群集策略 存储数据，而无需在多个 Redis 进程中分片。 它的行为类似于传统的单进程 Redis 服务器，仅适用于较小的缓存大小。
有关基础体系结构的详细信息，请参阅 Azure 托管 Redis 中的群集。
比较聚类策略
| 方面 | OSS | Enterprise | 非聚集 |
|---|---|---|---|
| 终结点和路由模型 | 客户端使用群集 API 直接连接到分片，以发现节点位置。 | 客户端连接到单个终结点;内部代理将请求路由到分片。 | 客户端连接到单个未分片实例。 |
| 客户端库要求 | 需要支持 Redis 群集 API 的客户端库。 | 适用于任何标准 Redis 客户端库;无需群集感知。 | 适用于任何标准 Redis 客户端库;无需群集感知。 |
| 性能特征 | 随着分片和 vCPU 的增加，直接分片连接通常会最大程度地减少延迟并最大化吞吐量。 | 与 OSS 相比，单节点代理可能会成为计算或网络吞吐量的瓶颈。 | 不能利用 Redis Enterprise 的多线程多分片设计，因此通常是性能最低的选项。 |
多键命令和 CROSSSLOT |
多键命令中的键必须映射到相同的哈希槽，否则命令将失败。 | 大多数多键命令必须以同一槽中的键为目标;允许跨槽使用一小部分命令。 | 没有槽位限制，因为数据没有分片。 |
| RediSearch 模块 | 不支持。 | 启用 RediSearch 时是必需的。 | 不适用;RediSearch 不提供非群集缓存。 |
| 最大缓存大小 | 在所有支持的缓存大小上都可用。 | 在所有支持的缓存大小上都可用。 | 仅限缓存大小为 25 GB 且更小。 |
| 主动异地复制 | 支持. | 支持. | 支持. |
| 群集管理命令 | 群集感知客户端所需的群集发现命令（例如 CLUSTER NODES）可用。 大多数修改或直接管理群集拓扑的命令仍然受阻，因为Azure管理拓扑。 |
Redis 群集发现和拓扑命令被阻止，包括CLUSTER INFO、CLUSTER HELP、CLUSTER KEYSLOTCLUSTER NODES和CLUSTER SLOTS。 |
群集管理命令不适用，因为缓存未分片。 |
| 创建后更改策略 | No. 删除并重新创建缓存以更改为其他策略。 | No. 删除并重新创建缓存以更改为其他策略。 | 是的，可以在部署后移动到群集策略，除非缓存位于活动异地复制组中。 |
客户端库兼容性
所有 Redis 客户端库都可以连接到使用企业群集策略的Azure托管 Redis 实例，因为缓存提供一个看起来非聚集的终结点。 如果选择 OSS 集群策略，请确认您的客户端库支持 Redis Cluster API，包括在分片迁移时跟随重定向。 大多数当前版本的常用 Redis 客户端库都支持群集 API，但较旧或专用库可能不是。 有关常用客户端库的列表，请参阅Azure托管 Redis 客户端库。
Azure管理每个策略下的群集拓扑，因此大多数直接修改或管理群集的命令仍被阻止。 OSS 群集策略提供了群集感知客户端定位分片并将请求路由到相应分片所需的发现命令。 企业策略不会公开 Redis 群集 API，因此也会阻止其群集发现命令。 由于 Microsoft 在内部管理群集拓扑，而企业策略会将该缓存呈现为非群集缓存，因此当你使用该策略时，包括 CLUSTER INFO、CLUSTER HELP、CLUSTER KEYSLOT、CLUSTER NODES 和 CLUSTER SLOTS 在内的命令都会被阻止。 使用 OSS 集群策略时，集群感知客户端库会使用诸如 CLUSTER NODES 之类的命令来发现分片位置，这是连接到缓存过程中的正常一部分；这些命令不会被阻止。 有关完整列表，请参阅被阻止的命令。
按库构建客户端
以下示例显示了选择单终结点或群集感知拓扑的高级客户端 API。 选择客户端库名称，即可打开完整的 Azure Managed Redis 身份验证示例（如果有可用示例）。 选择一个构造函数以打开客户端与该拓扑对应的连接指南。 非群集缓存使用与企业策略相同的客户端形式，因为两者都向客户端提供一个终结点。
以下链接中的 Azure 托管 Redis 示例（适用于 Lettuce、Jedis、node-redis、redis-py 和 go-redis）使用的是支持群集的客户端。 对于企业版或非群集版，请保留Azure托管 Redis 示例中的身份验证、TLS 和令牌刷新配置，但使用企业列中显示的标准客户端。 对于 OSS，可将该 Azure 托管 Redis 配置与 OSS 列中链接的群集指南结合起来。 当前的Azure托管 Redis 身份验证示例不包括 ioredis，因此 ioredis 链接涵盖其通用连接和群集设置。
对于生产环境中的连接，还应配置主机名和端口 10000、超时、重试行为以及连接重用或连接池。 使用 OSS 群集，首先连接到端口 10000 ，让客户端发现当前的分片端口。 不要对区域中发现的端口 85XX 进行硬编码，因为它们可能会更改。
概念级别的终结点和路由
比较表汇总了每个策略的终结点模型。 请记住的一个操作详细信息：使用 OSS 群集策略时，节点级连接详细信息可能会随着服务重新平衡分片而更改，因此请避免应用程序中的硬编码节点地址。 而是应依靠客户端库的集群发现机制，该机制会使用诸如 CLUSTER NODES 之类的命令来查找当前分片的位置。 借助企业群集策略，代理会代表客户端吸收这种复杂性，这也是该策略阻止直接客户端使用群集拓扑命令的原因。
性能权衡
OSS 群集策略通常提供最佳吞吐量和最低延迟，因为客户端直接连接到分片，并避免通过代理进行额外的网络跃点。 随着分片数量和 vCPU 数量的增加，吞吐量通常也会提升。 企业版集群策略以牺牲部分吞吐量上限为代价来换取简单性：由于所有请求都通过单个代理节点，因此该节点的计算和网络容量可能会先于底层分片成为限制因素。 非群集策略不受益于 Redis Enterprise 用于跨 vCPU 并行化工作的多线程多分片设计，因此它通常是三个选项中性能最低的。
确切的吞吐量和延迟取决于 SKU、性能层和流量模式。 有关对自己的实例进行基准测试的指导，请参阅使用 Azure 托管 Redis 进行性能测试。
多键命令和 CROSSSLOT 行为
由于Azure托管 Redis 实例在内部使用群集配置，因此对多个密钥进行操作的命令可能会根据群集策略返回CROSSSLOT错误：
- 使用 OSS 群集策略时，多键命令中引用的所有密钥都必须映射到相同的哈希槽。
- 在未启用主动异地复制的情况下，采用 企业群集策略 时，
DEL、MSET、MGET、EXISTS、UNLINK和TOUCH可跨槽运行。 其他多键命令要求键共享同一个槽位。 - 借助企业集群策略和主动异地复制，多键写入命令（如
DEL、MSET和UNLINK）要求相关键共享同一个槽位。 只有MGET，EXISTS并且TOUCH可以跨槽运行。 - 使用 非群集策略时，没有基于槽的限制，因为数据未分片。
如果应用程序跨任意键发出多键或事务命令（例如 MULTI），并且无法保证这些密钥共享哈希槽，请将这一要求纳入群集策略选择。 有关详细信息，请参阅 多键命令。
RediSearch 和模块要求
RediSearch 模块在全文搜索和矢量搜索功能下需要 企业群集策略。 无法使用 OSS 群集策略或非群集缓存启用 RediSearch。 RediSearch 还需要 NoEviction 逐出策略。 如果工作负荷需要搜索或矢量搜索功能，则会有效地为你做出聚类分析策略决策。 有关详细信息，请参阅 将 Redis 模块与 Azure 托管 Redis 配合使用 和 Azure 托管 Redis 中的矢量搜索。
缓存大小限制
如比较表中所示，非聚集策略上限为 25 GB。 如果希望数据超出该大小，请从 OSS 或企业版开始，或计划在达到限制之前更改策略。 有关详细信息，请参阅 稍后更改策略的功能。
主动异地复制注意事项
活动异地复制支持所有三个群集策略，但异地复制组中的每个缓存实例必须共享相同的配置，包括群集策略、SKU、容量、逐出策略和模块。 存在此要求是因为整个组的命令一致性（包括避免 CROSSSLOT 失败）取决于所有链接实例的行为方式相同。
由于此要求，在将缓存添加到异地复制组后，无法更改缓存的群集策略。 如果计划使用活动异地复制，请在将任何实例链接在一起之前确认群集策略选择。 有关详细信息，请参阅配置活动异地复制。
迁移兼容性
- 从Azure Cache for Redis基本层、标准层或高级层迁移：这些层通常是非聚集层。 迁移到 OSS 群集策略以提高性能，但可能需要更新客户端库配置来处理群集响应。 如果应用程序不能容忍群集拓扑，则非群集策略最多可用于 25 GB 的缓存。
有关详细信息，请参阅 在从基本层、标准层和高级层迁移之前了解差异。
以后能够更改策略
在创建缓存时将群集策略设置为 OSS 或 Enterprise 后，无法更改它。 若要在 OSS 和企业之间切换（或从其中任一策略中移开），必须删除缓存，并使用所需的策略重新创建缓存。
使用非群集策略创建的缓存例外：可以在部署后将其更新为群集配置，例如，如果需要超出 25 GB 非群集大小限制。 如果非群集缓存是活动异地复制组的一部分，则此可变性不适用，因为只要这些实例已链接，该组中的所有实例都必须保留相同的群集配置。
决策流
在预配缓存之前，请使用以下顺序缩小群集策略的范围：
- 工作负荷是否需要 RediSearch（全文搜索或矢量搜索）？ 如果是，请选择 企业群集策略。 其他任何策略都不支持 RediSearch。
- 你预计缓存现在或将来会增长到 25 GB 以上吗？ 如果是，并且不需要 RediSearch，请选择 OSS 或 Enterprise。 非群集策略上限为 25 GB。
- 客户端库是否支持 Redis 群集 API，包括群集发现和重定向？ 如果是，并且工作负载不需要 RediSearch， 则 OSS 群集策略 通常提供最佳性能。
- 您的客户端库是否只能以连接单个非集群服务器的方式进行连接？ 如果是这样，请选择 企业群集策略 ，实现广泛的兼容性，而无需群集感知客户端代码。
- 您的应用程序是否依赖于针对任意键执行的多键命令或事务命令，而这些键无法保证属于同一哈希槽？ 如果是这样，缓存大小将保持在 25 GB 或以下，请考虑 非群集策略 以避免
CROSSSLOT故障。 - 此缓存是否会参与活动异地复制？ 如果是，请立即确认群集策略。 计划链接到异地复制组的每个实例都必须使用相同的策略，并且一旦链接实例，就不能更改它。
预配检查清单
在创建Azure托管 Redis 实例之前，请确认以下内容：
- 你确定是需要 RediSearch 还是矢量搜索，因为这些功能需要企业群集策略和
NoEviction逐出策略。 - 如果您考虑采用 OSS 群集策略，请确认您的客户端库是否支持 Redis 群集 API。
- 您已估算缓存大小，并确认如果您正在考虑采用非群集策略，其仍可控制在 25 GB 的限制范围内，同时为未来增长预留余量。
- 你已检查应用程序是否会针对可能不共享同一哈希槽的多个键发出多键命令或事务命令，以及这是否与 OSS 或 Enterprise
CROSSSLOT的行为兼容。 - 你决定活动异地复制是否是设计中的一部分，如果是，则计划跨组中的每个实例使用相同的群集策略、SKU、容量、逐出策略和模块。
- 你了解 OSS 和企业群集策略在缓存实例的生存期是永久性的，而非群集缓存（异地复制组外部）稍后可以更新为群集策略。
- 如果你正从 Azure Cache for Redis 迁移，则需要审查源层级的集群行为，以确定 Azure Managed Redis 中最接近的对应策略。