Amazon ElastiCache
用户指南 (API Version 2015-02-02)
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。请点击 Amazon AWS 入门,可查看中国地区的具体差异

选择节点大小

本部分帮助您确定方案所需的节点实例类型。由于引擎 (Memcached 和 Redis) 实施集群的方式不同,因此您选择的引擎将使您的应用程序所需的节点大小变得不同。

为 Memcached 群集选择节点大小

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

群集总内存容量的计算方法是将群集中的节点数乘以每个节点的 RAM 容量。每个节点的容量都基于节点类型。

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

在某个场景中,您希望拥有 40GB 缓存内存,那么可以通过下列任一配置对其进行设置:

  • 13 cache.t2.medium 个节点,每个节点具有 3.22 GB 内存和 2 个线程,共 41.86 GB 和 26 个线程。

     

  • 7 cache.m3.large 个节点,每个节点具有 6.05 GB 内存和 2 个线程,共 42.35 GB 和 14 个线程。

    7 cache.m4.large 个节点,每个节点具有 6.42 GB 内存和 2 个线程,共 44.94 GB 和 14 个线程。

     

  • 3 cache.r3.large 个节点,每个节点具有 13.50 GB 内存和 2 个线程,共 40.50 GB 和 6 个线程。

    3 cache.m4.xlarge 个节点,每个节点具有 14.28 GB 内存和 4 个线程,共 42.84 GB 和 12 个线程。

比较节点选项

节点类型 内存 核心 小时成本* 需要的节点 总内存 核心总数 月度成本 †
cache.t2.medium 3.22GB 2 0.068 美元 13 41.86GB 26 636.48 美元
cache.m3.large 6.05GB 2 0.182 美元 7 42.35GB 14 917.28 美元
cache.m4.large 6.42GB 2 0.156 美元 7 44.94GB 14 768.24 美元
cache.r3.large 13.50GB 2 0.228 美元 3 40.50GB 6 492.48 美元
cache.m4.xlarge 14.28GB 4 0.311 美元 3 42.84GB 12 671.76 美元
* 自 2016 年 8 月 4 日起的每节点小时成本。
30 天(720 小时)的 100% 使用量的月度成本。

这些选项都提供了类似的内存容量,但提供了不同的计算容量和成本。要比较特定选项的成本,请参阅 Amazon ElastiCache 定价

对于运行 Memcached 的群集,每个节点上的部分可用内存都会用于连接开销。有关更多信息,请参阅 Memcached 连接开支

使用多个节点将需要跨这些节点分布密钥。每个节点都有自己的终端节点。为便于管理终端节点,可以使用 ElastiCache 的 Auto Discovery 功能,使客户端程序能够自动标识群集中的所有节点。有关更多信息,请参阅 节点自动发现 (Memcached)

如果您不确定您需要多少容量,对于测试,建议您从一个 cache.m3.medium 节点开始,然后使用发布到 CloudWatch 的 ElastiCache 指标监控内存使用率、CPU 利用率和缓存命中率。有关 ElastiCache 的 CloudWatch 指标的更多信息,请参阅使用 CloudWatch 指标进行监控。对于生产和大型工作负载,R3 节点提供了最佳性能和 RAM 成本价值。

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

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

为 Redis 群集选择节点大小

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

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

     

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

     

  • 您运行 Redis 的哪个版本?

     

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

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

    有关更多信息,请参阅下列内容:

     

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

     

    在拍摄快照或进行故障转移时,写操作密集的应用程序需要多得多的可用内存( 数据未使用的内存)。在执行 BGSAVE 过程时 – 在创建快照时、在将主集群与集群中的副本同步时、在启用仅附加文件 (AOF) 功能时或在将副本提升为主集群时(如果您有已启用自动故障转移功能的多可用区) – 您必须拥有足够的数据未使用内存才能容纳在 BGSAVE 过程期间执行的所有写入。最糟糕的情况是,在该过程期间重新写入所有 数据时,您需要的节点实例大小是数据所需的内存量的两倍。

     

    有关更多详细信息,请转至确保具有用于创建 Redis 快照的足够内存

     

  • 您的实现是一个独立的 Redis (已禁用集群模式)集群,还是具有多个分片的 Redis (已启用集群模式)集群?

     

    Redis (已禁用集群模式)集群

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

     

    例如,如果您估计您的所有项目的总大小为 12 GB,则可使用内存为 13.3 GB 的 cache.m3.xlarge 节点或内存为 13.5 GB 的 cache.r3.large 节点。但是,您可能需要更多内存才能执行 BGSAVE 操作。如果您的应用程序是写入操作密集型的,则您应将内存要求加倍到至少 24 GB,这意味着您应使用内存为 27.9 GB 的 cache.m3.2xlarge 或内存为 28.4 GB 的 cache.r3.rge

     

    具有多个分片的 Redis (已启用集群模式)

    如果您实现的是具有多个分片的 Redis (已启用集群模式)集群,则节点类型必须能够容纳 bytes-for-data-and-overhead / number-of-shards 字节的数据。

     

    例如,如果您估计所有项目的总大小为 12 GB,并且您具有 2 个分片,则可使用内存为 6.05 GB 的 cache.m3.large 节点 (12 GB/2)。但是,您可能需要更多内存才能执行 BGSAVE 操作。如果您的应用程序是写入操作密集型的,则您应将内存要求加倍到至少每分片 12 GB,这意味着您应使用内存为 13.3 GB 的 cache.m3.xlarge 或内存为 13.5 GB 的 cache.r3.large

     

    当前,您无法向 Redis (已启用集群模式)集群添加分片。因此,您可能需要使用较大的节点类型来适应预期增长。

     

您的集群运行期间,您可以监控发布到 CloudWatch 的内存使用率、处理器利用率、缓存命中数和缓存未命中数指标。如果群集的命中率不高,或是您发现移出键的频率太高,则可以选择 CPU 和内存规格更高的不同节点大小。

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