本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 选择节点大小
<a name="CacheNodes.SelectSize"></a>

为 ElastiCache 集群选择的节点大小会影响成本、性能和容错能力。

## 节点大小（Valkey 和 Redis OSS）
<a name="CacheNodes.SelectSize.redis"></a>

有关 Graviton 处理器的优势的信息，请参阅 [AWS Graviton 处理器](https://aws.amazon.com/pm/ec2-graviton/)。

回答以下问题可帮助您决定实施 Valkey 或 Redis OSS 所需的最小节点类型：
+ 是否预期会出现采用多个客户端连接但吞吐量受限的工作负载？

  如果是这种情况，并且您运行的是 Redis OSS 版本 5.0.6 或更高版本，则可以为 Redis OSS 引擎使用增强型 I/O 功能来获得更好的吞吐量和延迟，此时可用的 CPU 用于分载客户端连接。如果您运行的是 Redis OSS 版本 7.0.4 或更高版本，则除了增强型 I/O 之外，您还将通过增强型 I/O 多路复用来获得额外的加速，此时，每个专用网络 IO 线程利用 Redis OSS 高效地批量处理命令的能力，将来自多个客户端的命令通过管道传送到 Redis OSS 引擎。在 ElastiCache for Redis OSS 7.1 及更高版本中，我们扩展了增强型 I/O 线程功能，使其还可以处理表示层逻辑。对于表示层，这是指增强型 I/O 线程现在不仅可以读取客户端输入，还可以将输入解析为 Redis OSS 二进制命令格式，然后将其转发到主线程以便执行，从而提高性能。有关更多详细信息，请参阅[博客文章](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/)和[支持的版本](VersionManagement.md#supported-engine-versions)页面。
+ 您是否有仅会经常访问少部分数据的工作负载？

  如果是这种情况，并且您运行的是 Redis OSS 6.2 版或更高版本的引擎，您可以通过选择 r6gd 节点类型来使用数据分层功能。使用数据分层功能时，最近极少使用的数据将存储到 SSD 中。在检索这些数据时，虽然延迟会轻微增加，但是可以节省成本。有关更多信息，请参阅 [ElastiCache 中的数据分层](data-tiering.md)。

  有关更多信息，请参阅 [受支持的节点类型](CacheNodes.SupportedTypes.md)。
+ 您的数据共需要多少内存量？

  要获得一般估计值，请取要缓存的项目的大小。将此大小乘以同时要保留在缓存中的项目数。要获得项目大小的合理估计值，请先序列化您的缓存项目，再计算字符数。然后将该值除以集群中的分区数。

  有关更多信息，请参阅 [受支持的节点类型](CacheNodes.SupportedTypes.md)。
+ 您运行 Redis OSS 的哪个版本？

  对于 2.8.22 版之前的 Redis，您需要预留更多内存以用于失效转移、快照、同步和将副本提升为主节点的操作。之所以有此要求，是因为您必须具有足够的内存来执行过程中的所有写入。

  Redis OSS 2.8.22 和更高版本使用无分支保存过程，相比之前的过程，所需可用内存更少。

  有关更多信息，请参阅下列内容：
  + [如何实施同步和备份](Replication.Redis.Versions.md)
  + [确保具有用于创建 Valkey 或 Redis OSS 快照的足够内存](BestPractices.BGSAVE.md)
+ 您的应用程序的写操作有多密集？

  在拍摄快照或进行故障转移时，写操作密集的应用程序需要多得多的可用内存（ 数据未使用的内存）。无论何时执行 `BGSAVE` 进程，必须有足够的、数据未使用的内存，以容纳在 `BGSAVE` 过程中执行的所有写入。例如，拍摄快照时、将主集群与集群中的副本同步时以及启用仅附加文件 (AOF) 功能时。另一个示例是将副本提升为主节点时（如果您启用了多可用区）。最糟糕的情况是在此过程中重写所有数据。在这种情况下，您需要的节点实例大小是数据所需的内存量的两倍。

  有关更多详细信息，请参阅 [确保具有用于创建 Valkey 或 Redis OSS 快照的足够内存](BestPractices.BGSAVE.md)。
+ 您的实施是一个独立的 Valkey 或 Redis OSS（已禁用集群模式）集群，还是具有多个分片的 Valkey 或 Redis OSS（已启用集群模式）集群？

**Valkey 或 Redis OSS（已禁用集群模式）集群**  
如果您实施的是 Valkey 或 Redis OSS（已禁用集群模式）集群，则节点类型必须能够容纳所有数据及必要的开销，如上一要点中所述。

  例如，假设您估计所有项目的总大小为 12GB。在此情况下，您可以使用具有 13.3GB 内存的 `cache.m3.xlarge` 节点 或具有 13.5GB 内存的 `cache.r3.large` 节点。但是，您可能需要更多内存才能执行 `BGSAVE` 操作。如果您的应用程序写入操作繁重，请将内存要求翻倍至至少 24GB。因此，使用具有 27.9GB 内存的 `cache.m3.2xlarge` 或具有 30.5GB 内存的 `cache.r3.xlarge`。

**具有多个分片的 Valkey 或 Redis OSS 集群（已启用集群模式）**  
如果您实施的是具有多个分片的 Valkey 或 Redis OSS（已启用集群模式）集群，则节点类型必须能够容纳 `bytes-for-data-and-overhead / number-of-shards` 字节的数据。

  例如，假设您估计所有项目的总大小为 12GB 且您具有两个分区。在此情况下，您可以使用具有 6.05GB 内存的 `cache.m3.large` 节点（12GB/2）。但是，您可能需要更多内存才能执行 `BGSAVE` 操作。如果您的应用程序写入操作繁重，请将内存要求翻倍至至少每个分区 12GB。因此，使用具有 13.3GB 内存的 `cache.m3.xlarge` 或具有 13.5GB 内存的 `cache.r3.large`。
+ 您是否正在使用 Local Zones？

[Local Zones](Local_zones.md) 使您能够将 ElastiCache 集群等资源放置在靠近用户的多个位置。但是，当您选择节点大小时，请注意，无论容量要求如何，本次可用节点大小目前仅限于以下内容：
  + 最新一代：

    **M5 节点类型：**、`cache.m5.large`、`cache.m5.xlarge`、`cache.m5.2xlarge`、`cache.m5.4xlarge`、`cache.m5.12xlarge``cache.m5.24xlarge`

    **R5 节点类型：**、`cache.r5.large`、`cache.r5.xlarge`、`cache.r5.2xlarge`、`cache.r5.4xlarge`、`cache.r5.12xlarge``cache.r5.24xlarge`

    **T3 节点类型：**、`cache.t3.micro`、`cache.t3.small``cache.t3.medium`

您的集群运行期间，您可以监控发布到 CloudWatch 的内存使用率、处理器利用率、缓存命中数和缓存未命中数指标。您可能会注意到您的集群没有您想要的命中率，或者密钥被移出的频率过于频繁。在这些情况下，您可以选择具有较高 CPU 和内存规格的不同节点大小。

监控 CPU 使用情况时，请记住 Valkey 和 Redis OSS 是单线程的。因此，将报告的 CPU 使用率乘以 CPU 核心数来获得实际使用量。例如，报告的使用率为 20% 的四核 CPU 实际上相当于一个使用率为 80% 的单核 Redis OSS。

## 节点大小（Memcached）
<a name="CacheNodes.SelectSize.Mem"></a>

Memcached 集群包含一个或多个节点，该集群的数据会分区到各个节点中。因此，集群的内存需求和节点的内存相关但不相同。您可以通过拥有几个大型节点或多个小型节点来获得所需的集群内存容量。此外，由于您的需求是变化的，您可以在集群中添加节点或删除节点，从而仅为所需内容付费。

集群的总内存容量的计算方法是，在扣除系统开销后将集群中的节点数乘以每个节点的 RAM 容量。每个节点的容量都基于节点类型。

```
cluster_capacity = number_of_nodes * (node_capacity - system_overhead)
```

集群中的节点数是运行 Memcached 的集群可用性的一个关键因素。如果单一节点出现故障，则可能对应用程序的可用性以及后端数据库的负载产生影响。在这种情况下，ElastiCache 会更换出现故障的节点并对其进行重新填充。要减小这种可用性影响，请将内存和计算容量分布于更多节点上（每个节点的容量稍小），而非使用少量大容量节点。

在您希望拥有 35GB 缓存内存的情况下，可以设置以下任意配置：
+ 11 `cache.t2.medium` 个节点，每个节点具有 3.22 GB 内存和 2 个线程，共 35.42 GB 和 22 个线程。
+ 6 `cache.m4.large` 个节点，每个节点具有 6.42 GB 内存和 2 个线程，共 38.52 GB 和 12 个线程。
+ 3 `cache.r4.large` 个节点，每个节点具有 12.3 GB 内存和 2 个线程，共 36.90 GB 和 6 个线程。
+ 3 `cache.m4.xlarge` 个节点，每个节点具有 14.28 GB 内存和 4 个线程，共 42.84 GB 和 12 个线程。


**比较节点选项**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonElastiCache/latest/dg/CacheNodes.SelectSize.html)

这些选项都提供了类似的内存容量，但提供了不同的计算容量和成本。要比较特定选项的成本，请参阅 [Amazon ElastiCache 定价](https://aws.amazon.com/elasticache/pricing/)。

对于运行 Memcached 的集群，每个节点上的部分可用内存都会用于连接开销。有关更多信息，请参阅 [Memcached 连接开销](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead)

使用多个节点需要跨这些节点分布密钥。每个节点都有自己的终端节点。为了便于管理端点，您可以使用 ElastiCache（Auto Discovery 功能）以使客户端程序能够自动标识集群中的所有节点。有关更多信息，请参阅 [自动识别集群（Memcached）中的节点](AutoDiscovery.md)。

在某些情况下，您可能无法确定您需要多少容量。如果是这样，对于测试，我们建议从 `cache.m5.large` 节点开始。然后，使用发布到 Amazon CloudWatch 的 ElastiCache 指标监控内存使用率、CPU 利用率和缓存命中率。有关 ElastiCache 的 CloudWatch 指标的更多信息，请参阅 [使用 CloudWatch 指标监控使用情况](CacheMetrics.md)。对于生产和大型工作负载，R5 节点提供了最佳性能和 RAM 成本价值。

如果您的集群没有所需的命中率，您可以轻松地添加更多的节点，从而增加您的集群的可用内存总量。

如果集群受到 CPU 的约束，但具有足够的命中率，请使用提供更强计算能力的节点类型来设置新集群。