Amazon ElastiCache 常见问题

问：节点替换需要多长时间？

替换通常在几分钟内即可完成。对于某些实例配置和流量模式，替换可能需要较长时间。例如，Redis 主节点可能没有足够的可用内存，因此可能会出现较高的写入流量。当某个空副本与该主节点同步时，主节点会尝试在处理传入的写入流量的同时进行副本同步，因此可能导致内存不足。在这种情况下，主节点会断开与副本的连接，并重新启动同步进程。可能需要经过几次尝试，副本才能同步成功。如果传入的写入流量始终较高，副本也有可能一直无法同步。

Memcached 节点在替换期间无需同步，而且无论节点规模如何，始终都能快速完成替换。

问：节点替换对应用程序有何影响？

对于 Redis 节点，替换过程旨在尽量保留现有数据，同时需要 Redis 复制成功。对于单节点 Redis 集群，ElastiCache 会动态启动一个副本，复制数据，然后故障转移到该副本。对于由多个节点组成的复制组，ElastiCache 会替换现有副本，并将数据从主节点同步到新副本。如果启用多可用区或集群模式，替换主副本将会触发故障转移至只读副本的操作。如果禁用了多可用区，ElastiCache 将替换主副本，然后同步只读副本中的数据。在此期间，主副本将不可用。

对于 Memcached 节点，替换过程中会产生空的新节点，并会终止当前节点。在切换过程中，新节点将在短时间内不可用。完成切换后，您的应用程序可能会出现性能下降的情况，而空的新节点会通过缓存数据进行填充。

问：为了获得顺畅的替换体验并最大限度减少数据丢失，应遵循哪些最佳实践？

对于 Redis 节点，替换过程旨在尽量保留现有数据，同时需要 Redis 复制成功。我们会尝试从同一集群中一次性替换刚好足够的节点，以确保该集群的稳定性。您可以将主副本和只读副本预置在不同的可用区内。这样，在替换某个节点时，将通过另一个可用区内的对等节点同步数据。对于单节点 Redis 集群，我们建议您为 Redis 提供足够的内存，如此处所述。对于具有多个节点的 Redis 复制组，我们还建议在传入写入流量较低的时段安排替换。

对于 Memcached 节点，将维护时段安排在传入写入流量较低的时段，对应用程序进行故障转移测试，并使用 ElastiCache 提供的“更智能”的客户端。数据丢失无法避免，因为 Memcached 的所有数据都存储在内存中。

问：如何自行管理节点替换？

我们建议您允许 ElastiCache 在计划维护时段管理节点替换。创建 ElastiCache 集群时，您可以通过每周维护时段指定首选替换时间。之后您可以使用 ModifyCacheCluster API 或在 ElastiCache 管理控制台中单击“修改”，将维护时段改为更方便的时段。

如果您选择自行管理替换，可以根据您的使用案例和集群配置采取各种操作：

• 更改维护时段。
• 使用备份和还原过程重新启动 Redis 实例。
• 如果 Redis 集群配置已禁用集群模式
  • 替换只读副本（禁用集群模式）– 手动替换 Redis 复制组中只读副本的过程。
  • 替换主节点（禁用集群模式）– 手动替换 Redis 复制组中主节点的过程。
  • 替换独立节点（禁用集群模式）– 替换独立 Redis 节点的两种不同过程。
• 如果 Redis 集群配置已启用集群模式
  • 将集群中的节点替换为一个或多个分片 – 您可以使用备份和还原，也可以先扩展再缩减来替换节点。

有关所有这些选项的更多说明，请参阅计划替换节点时可以采取的操作页面。

对于 Memcached，您只需删除集群再重新创建即可。替换后，实例将不再具有与之相关联的计划事件。

问：为什么要进行这些节点替换？

只有在对这些节点进行替换之后，才能将强制性的软件更新应用到底层主机。此类更新有助于增强安全性、可靠性和操作性能。

问：这些替换是否会同时影响我在多个可用区中的节点？

我们可以根据集群配置在同一集群中替换多个节点，同时确保集群的稳定性。对于 Redis 分片集群，我们尽量不在同一分片中同时替换多个节点。此外，我们还尽量不在跨所有分片的集群中替换大多数主节点。

对于非分片集群，我们尽量在维护时段将节点替换的时间错开，以尽可能地保持集群的稳定性。

问：可以同时替换来自不同区域的不同集群中的节点吗？

可以。如果您为这些集群配置了相同的维护时段，则可以同时对这些节点进行替换。

问：Amazon ElastiCache for Redis 有哪些性能优势？

ElastiCache for Redis 提供增强型 I/O 线程，通过多路复用、表示层卸载等方式，大规模显著提高吞吐量并降低延迟。通过利用更多内核来处理 I/O 并动态调整工作负载，增强型 I/O 线程提高了性能。ElastiCache for Redis 通过将加密转移到相同的增强型 I/O 线程来提高 TLS 支持型集群的吞吐量。ElastiCache for Redis 版本 7.0 引入了增强型 I/O 多路复用，将许多客户端请求合并到一个通道中，并提高了 Redis 主线程的效率。在 ElastiCache for Redis 7.1 及更高版本中，我们扩展了增强型 I/O 线程功能，使其还能处理表示层逻辑（请参见博客）。增强型 I/O 线程不仅可以读取客户端输入，还可以将输入解析为 Redis 二进制命令格式，然后将其转发到主线程执行，以提高性能。使用 ElastiCache for Redis 版本 7.1，与 ElastiCache for Redis 版本 7.0 相比，吞吐量最多可以提高 100%，P99 延迟降低 50%。在 r7g.4xlarge 或更大节点上，您可以实现每个节点每秒超过 100 万次请求（RPS）。

问：如何监控 Redis 的 CPU 利用率？

Amazon ElastiCache 提供了两个指标来衡量 Amazon ElastiCache for Redis 工作负载的 CPU 利用率 – EngineCPUUtilization 和 CPUUtilization。CPUUtilization 指标衡量实例（节点）的 CPU 利用率，EngineCPUUtilization 指标衡量 Redis 进程级别的利用率。除了 CPUUtilization 指标外，您还需要 EngineCPUUtilization 指标，因为主 Redis 进程是单线程的，并且仅使用实例上可用的多个 CPU 内核中的一个 CPU。因此，CPUUtilization 指标无法精确查看 Redis 进程级别的 CPU 利用率。

我们建议您同时使用 CPUUtilization 和 EngineCPUUtilization 指标，以详细了解 Redis 集群的 CPU 利用率。这两个指标在所有 Amazon Web Services 区域都可用，您可以使用 CloudWatch 或通过 Amazon Web Services 管理控制台访问这些指标。

此外，我们建议您访问此页面以了解性能监控的有用指标。