选择节点大小 - Amazon ElastiCache for Redis

选择节点大小

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

选择节点大小

回答以下问题可帮助您决定实施 Redis 所需的最小节点类型:

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

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

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

  • 您运行 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 集群等资源放置在靠近用户的多个位置。但是,当您选择节点大小时,请注意,无论容量要求如何,本次可用节点大小目前仅限于以下内容:

    • 最新一代:

      M5 节点类型:cache.m5.largecache.m5.xlargecache.m5.2xlargecache.m5.4xlargecache.m5.12xlargecache.m5.24xlarge

      R5 节点类型:cache.r5.largecache.r5.xlargecache.r5.2xlargecache.r5.4xlargecache.r5.12xlargecache.r5.24xlarge

      T3 节点类型:cache.t3.microcache.t3.smallcache.t3.medium

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

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