你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
针对 Enterprise 层和 Enterprise Flash 层的最佳做法是什么
下面是使用 Azure Cache for Redis 的 Enterprise 层和 Enterprise Flash 层时的最佳做法。
区域冗余
强烈建议在区域冗余配置中部署新的缓存。 区域冗余可确保 Redis Enterprise 节点分布在三个可用性区域中，提高了数据中心级故障冗余。 使用区域冗余可提高可用性。 有关详细信息，请参阅联机服务的服务级别协议 (SLA)。
区域冗余在 Enterprise 层中非常重要，因为缓存实例总是使用至少三个节点。 两个数据节点（负责保存数据）和一个“仲裁节点”。 增加容量时，数据节点数会按偶数递增缩放。
还有另外一个节点叫做仲裁节点。 该节点监视数据节点，并在发生故障转移时自动选择新的主节点。 区域冗余可确保节点均匀分布在三个可用性区域中，从而最大限度地降低仲裁丢失的可能性。 除了区域内带宽费用之外，客户无需为仲裁节点付费，也无需为使用区域冗余付费。
扩展
在 Azure Cache for Redis 的 Enterprise 和 Enterprise Flash 层中，建议优先考虑纵向扩展而不是横向扩展。优先考虑纵向扩展是因为 Enterprise 层是在 Redis Enterprise 的基础上构建的，后者能够在更大的 VM 中利用更多的 CPU 核心。
反之，对于在开源 Redis 的基础上构建的“基本”、“标准”和“高级”层，建议正好相反。 在这些层中，大多数情况下建议优先考虑横向扩展而非纵向扩展。
分片和 CPU 利用率
在 Azure Cache for Redis 的基本层、标准层和高级层中，确定使用的虚拟 CPU (vCPU) 数量非常简单。 每个 Redis 节点在专用 VM 上运行。 Redis 服务器进程是单线程的，在每个主节点和每个副本节点上使用一个 vCPU。 VM 上的其他 vCPU 仍然用于其他活动，例如不同任务的工作流协调、运行状况监视和 TLS 负载等。
使用群集时，效果是将数据分布到更多节点上，每个节点一个分片。 通过增加分片的数量，可以根据群集中分片的数量线性增加使用的 vCPU 的数量。
另一方面，Redis Enterprise 可以为 Redis 实例本身使用多个 vCPU。 换句话说，Azure Cache for Redis 的所有层都可以使用多个 vCPU 来执行后台和监视任务，但只有 Enterprise 和 Enterprise Flash 层能够在每个 VM 上为 Redis 分片使用多个 vCPU。 该表显示了用于每个 SKU 和容量（即横向扩展）配置的有效 vCPU 数量。
这些表格显示了用于主分片的 vCPU 数量，而不是副本分片的数量。 分片并不与 vCPU 的数量一一对应。 表格仅说明 vCPU，而不是分片。 某些配置使用比可用 vCPU 更多的分片，以在某些使用方案中提升性能。
E5
| 容量 | 有效的 vCPU |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| 容量 | 有效的 vCPU |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| 容量 | 有效的 vCPU |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| 容量 | 有效的 vCPU |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| 容量 | 有效的 vCPU |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| 容量 | 有效的 vCPU |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| 容量 | 有效的 vCPU |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| 容量 | 有效的 vCPU |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| 容量 | 有效的 vCPU |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| 容量 | 有效的 vCPU |
|---|---|
| 3 | 30 |
| 9 | 90 |
Enterprise 上的群集
与基本层、标准层和高级层相比，Enterprise 和 Enterprise Flash 层本质上进行了群集处理。 实现取决于所选择的群集策略。 Enterprise 层提供两个群集策略选项：OSS 和 Enterprise。 对于大多数应用程序，建议使用 OSS 群集策略，因为它支持更高的最大吞吐量，但每个版本都有优缺点。
OSS 群集策略实现与开源 Redis 相同的 Redis 群集 API。 Redis 群集 API 允许 Redis 客户端直接连接到每个 Redis 节点，从而最大程度地减少延迟并优化网络吞吐量。 因此，当横向扩展具有更多节点的群集时，可以获得接近线性的可伸缩性。 OSS 群集策略通常提供最佳的延迟和吞吐量性能，但是需要客户端库支持 Redis 群集。 OSS 群集策略也不能与 RediSearch 模块一起使用。
Enterprise 群集策略是一种更简单的配置，它将单个终结点用于所有客户端连接。 使用 Enterprise 群集策略将所有请求路由到一个 Redis 节点，然后该节点用作代理，在内部将请求路由到群集中的正确节点。 这种方法的优点是 Redis 客户端库无需支持 Redis 群集即可利用多个节点。 缺点是单节点代理可能会成为影响计算利用率或网络吞吐量的瓶颈。 Enterprise 群集策略是唯一可与 RediSearch 模块一起使用的策略。
多键命令
由于 Enterprise 层使用群集配置，你可能会看到对多个键进行操作的命令上出现 CROSSSLOT 异常。 行为因使用的群集策略而异。 如果使用 OSS 群集策略，多键命令需要所有键都映射到同一个哈希槽。
你可能还会看到 Enterprise 群集策略的 CROSSSLOT 错误。 在具有 Enterprise 群集的槽中，仅允许使用以下多键命令：DEL、MSET、MGET、EXISTS、UNLINK 和 TOUCH。
在 Active-Active 数据库中，只能对同一槽中的键运行多键写入命令（DEL、MSET、UNLINK）。 但是，在 Active-Active 数据库中的各个槽之间允许使用以下多键命令：MGET、 EXISTS 和 TOUCH。 有关更多信息，请参阅数据库群集。
Enterprise Flash 最佳做法
Enterprise Flash 层既使用 NVMe Flash 存储又使用 RAM。 由于 Flash 存储成本更低，因此使用 Enterprise Flash 层可以以损失部分性能为代价换取更高的性价比。
在 Enterprise Flash 实例上，20% 的缓存空间位于 RAM 上，而其他 80% 使用 Flash 存储。 所有密钥都存储在 RAM 上，而值可以存储在 Flash 存储或 RAM 中。 值的位置由 Redis 软件智能确定。 经常访问的“热”值存储在 RAM 上，而不太常用的“冷”值保存在 Flash 上。 在读取或写入数据之前，必须将其移动到 RAM，成为“热”数据。
由于 Redis 将进行优化以获得最佳性能，因此在向 Flash 存储添加项之前，该实例将首先填满可用的 RAM。 这对性能有一些影响：
- 在内存使用率较低的情况下进行测试时，性能和延迟可能明显好于使用完整缓存实例，因为仅使用 RAM。
- 向缓存写入更多数据时，与 Flash 存储相比，RAM 中的数据比例会降低，这通常也会降低延迟和吞吐量性能。
非常适合 Enterprise Flash 层的工作负载
在 Enterprise Flash 层上可能运行良好的工作负载通常具有以下特征：
- 读取量很大，读取命令与写入命令的比率较高。
- 访问侧重于一部分键，这些键的使用频率比数据集的其他部分高得多。
- 与键名相比，值相对较大。 （由于键名始终存储在 RAM 中，因此这可能成为内存增长瓶颈。）
不太适合 Enterprise Flash 层的工作负载
某些工作负载的访问特征针对 Flash 层设计进行的优化较少：
- 写入大量工作负载。
- 在大多数数据集中采用随机或统一数据访问模式。
- 长键名称的值大小相对较小。
使用活动异地复制处理区域故障情况
活动异地复制是一项强大的功能，可用于在使用 Azure Cache for Redis 的 Enterprise 层时大幅提高可用性。 但是，如果出现区域性中断，应该采取措施准备缓存。
例如，考虑以下提示：
- 如果某个区域出现故障，请提前确定要切换到的异地复制组中的其他缓存。
- 确保设置了防火墙，以便任何应用程序和客户端都可以访问标识的备份缓存。
- 异地复制组中的每个缓存都有自己的访问密钥。 确定应用程序在定位备份缓存时如何切换到不同的访问密钥。
- 如果异地复制组中的一个缓存出现故障，异地复制组中的所有缓存中就会开始累积元数据。 在写入可以再次同步到所有缓存之前，不能放弃元数据。 可通过强制取消链接关闭的缓存来防止元数据累积。 考虑监视缓存中的可用内存，如果存在内存压力，则取消链接，尤其是对于写入密集型工作负载。
也可以使用断路器模式。 使用该模式自动将流量从遇到区域故障的缓存重定向到同一异地复制组中的备份缓存。 使用 Azure 服务，如 Azure 流量管理器或 Azure 负载均衡器来启用重定向。
数据持久化与数据备份
Enterprise 和 Enterprise Flash 层中的数据持久化功能旨在当缓存出现故障时自动为数据提供快速恢复点。 通过将 RDB 或 AOF 文件存储在装载到缓存实例的托管磁盘中，可以实现快速恢复。 用户无法访问磁盘上的持久化文件。
许多客户希望使用持久化来定期备份其缓存中的数据。 不建议以这种方式使用数据持久化。 请使用导入/导出功能。 可以将 RDB 格式的缓存数据副本直接导出到选择的存储帐户中，并根据需要随时触发数据导出。 可以通过门户或使用 CLI、PowerShell 或 SDK 工具来触发导出。