选择节点大小

是否预期会出现采用多个客户端连接但吞吐量受限的工作负载？

如果是这种情况，并且您运行的是 Redis 版本 5.0.6 或更高版本，则可以为 Redis 引擎使用增强型 I/O 功能来获得更好的吞吐量和延迟，此时可用的 CPU 用于分载客户端连接。如果您运行的是 Redis 版本 7.0.4 或更高版本，则除了增强型 I/O 之外，您还将通过增强型 I/O 多路复用来获得额外的加速，此时，每个专用网络 IO 线程利用 Redis 高效地批量处理命令的能力，将来自多个客户端的命令通过管道传送到 Redis 引擎。在 ElastiCache for Redis v7.1 及更高版本中，我们扩展了增强型 I/O 线程功能，使其还可以处理表示层逻辑。对于表示层，这是指增强型 I/O 线程现在不仅可以读取客户端输入，还可以将输入解析为 Redis 二进制命令格式，然后将其转发到主线程以便执行，从而提高性能。有关更多详细信息，请参阅博客文章和支持的版本页面。

您是否有仅会经常访问少部分数据的工作负载？

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

有关更多信息，请参阅受支持的节点类型。

您的数据共需要多少内存量？

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

有关更多信息，请参阅受支持的节点类型。

您运行 Redis 的哪个版本？

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

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

有关更多信息，请参阅下列内容：

您的应用程序的写操作有多密集？

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

有关更多详细信息，请参阅 确保具有用于创建 Redis 快照的足够内存。

您的实施是一个独立的 Redis（已禁用集群模式）集群，还是具有多个分区的 Redis（已启用集群模式）集群？

Redis（已禁用集群模式）集群

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

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

具有多个分区的 Redis（已启用集群模式）

如果您实施的是具有多个分区的 Redis （已启用集群模式）集群，则节点类型必须能够容纳 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 使您能够将 ElastiCache 集群等资源放置在靠近用户的多个位置。但是，当您选择节点大小时，请注意，无论容量要求如何，本次可用节点大小目前仅限于以下内容：