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

# Amazon ElastiCache Well-Architected Lens 可靠性支柱
<a name="ReliabilityPillar"></a>

可靠性支柱的侧重点是执行预期功能的工作负载以及如何从故障中快速恢复以满足需求。关键主题包括分布式系统设计、恢复规划和适应不断变化的需求。

**Topics**
+ [REL 1：您如何支持高可用性（HA）架构部署？](#ReliabilityPillarREL1)
+ [REL 2：您如何使用 ElastiCache 实现恢复点目标（RPO）？](#ReliabilityPillarREL2)
+ [REL 3：您如何支持灾难恢复（DR）要求？](#ReliabilityPillarREL3)
+ [REL 4：如何有效地规划失效转移？](#ReliabilityPillarREL4)
+ [REL 5：您的 ElastiCache 组件是否设计为可扩展？](#ReliabilityPillarREL5)

## REL 1：您如何支持高可用性（HA）架构部署？
<a name="ReliabilityPillarREL1"></a>

**问题级简介：**了解 Amazon ElastiCache 的高可用性架构，将使您能够在可用性事件期间以弹性状态运行。

**问题级优势：**设计您的 ElastiCache 集群的架构，使之具有故障恢复能力，可确保您的 ElastiCache 部署具有更高的可用性。
+ **[必需] **确定您的 ElastiCache 集群所需的可靠性级别。不同的工作负载具有不同的弹性标准，从完全的临时工作负载到任务关键型工作负载。定义您运行的每种环境类型（例如开发、测试和生产）的需求。

  缓存引擎：ElastiCache for Memcached 与 ElastiCache for Valkey 和 ElastiCache for Redis OSS

  1. ElastiCache for Memcached 不提供任何复制机制，主要用于临时工作负载。

  1. ElastiCache for Valkey 和 ElastiCache for Redis OSS 提供了下面所讨论的 HA 功能
+ **[最佳] **对于需要 HA 的工作负载，请在集群模式下使用 ElastiCache，每个分片至少有两个副本，即使对于吞吐量要求较小且只需要一个分片的工作负载也是如此。

  1. 如果启用了集群模式，将自动启用多可用区。

     在发生任何计划内或计划外维护以及缓解可用区故障时，多可用区通过执行从主节点到副本的自动失效转移来最大限度地减少停机时间。

  1. 对于分片工作负载，由于 Valkey 或 Redis OSS 集群协议要求大多数主节点可用才能实现仲裁，因此至少有三个分片可以在失效转移事件期间提供更快的恢复。

  1. 跨可用性设置两个或更多副本。

     拥有两个副本可以提高读取可扩展性，也可以在一个副本处于维护状态的场景中提供读取可用性。

  1. 使用基于 Graviton2 的节点类型（大多数区域中的原定设置节点）。

     ElastiCache 在这些节点上添加了优化的性能。因此，您可以获得更佳的复制和同步性能，从而提高整体可用性。

  1. 监控并适当调整规模以应对预期的流量高峰：在高负载下，引擎可能会变得无响应，从而影响可用性。`BytesUsedForCache` 和 `DatabaseMemoryUsagePercentage` 是衡量内存使用情况的良好指标，而 `ReplicationLag` 是基于写入速率衡量复制运行状况的指标。您可以使用这些指标来触发集群扩展。

  1. 通过[在生产失效转移事件之前使用失效转移 API](https://docs.amazonaws.cn/en_us/AmazonElastiCache/latest/APIReference/API_TestFailover.html) 进行测试，确保客户端恢复能力。

  **[资源]：**
  + [配置 ElastiCache for Redis OSS 以提高可用性](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
  + [使用复制组时的高可用性](Replication.md)

## REL 2：您如何使用 ElastiCache 实现恢复点目标（RPO）？
<a name="ReliabilityPillarREL2"></a>

**问题级简介：**了解工作负载 RPO，为有关 ElastiCache 备份和恢复策略的决策提供依据。

**问题级优势：**制定适当的 RPO 策略，可以提高灾难恢复情景下的业务连续性。设计备份和还原策略有助于您实现 ElastiCache 数据的恢复点目标（RPO）。ElastiCache 提供存储在 Amazon S3 中的快照功能以及可配置的保留策略。这些快照是在定义的备份时段内拍摄的，并由服务自动处理。如果您的工作负载需要额外的备份粒度，则可以选择每天创建多达 20 个手动备份。手动创建的备份没有服务保留策略，可以无限期保留。
+ **[必需] **了解并记录您的 ElastiCache 部署的 RPO。
  + 请注意，Memcached 不提供任何备份流程。
  + 查看 ElastiCache 备份和还原特性的功能。
+ **[最佳] **制定一个沟通良好的集群备份流程。
  + 根据需要启动手动备份。
  + 查看自动备份的保留策略。
  + 请注意，手动备份将会无限期保留。
  + 将自动备份安排在使用率比较低的时段内进行。
  + 对只读副本执行备份操作，以确保将对集群性能的影响降至最低。
+ **[良好]** 利用 ElastiCache 的计划备份功能，在规定的时段内定期备份数据。
  + 定期测试从备份中执行的还原。
+ **[资源]：**
  + [Redis OSS](https://aws.amazon.com/elasticache/faqs/#Redis)
  + [ElastiCache 的备份与恢复](backups.md)
  + [进行手动备份](backups-manual.md)
  + [计划自动备份](backups-automatic.md)
  + [备份和还原 ElastiCache 集群](https://aws.amazon.com/blogs/aws/backup-and-restore-elasticache-redis-nodes/)

## REL 3：您如何支持灾难恢复（DR）要求？
<a name="ReliabilityPillarREL3"></a>

**问题级简介：**灾难恢复对于任何工作负载规划都是一个重要的方面。ElastiCache 提供了多种选择，可根据工作负载弹性要求实施相应的灾难恢复。使用 Amazon ElastiCache 全局数据存储，您可以在一个区域中写入您的集群，并让数据可供从另外两个跨区域副本集群读取，从而实现跨区域的低延迟读取和灾难恢复。

**问题级优势：**了解各种灾难情景并相应进行规划可以确保业务连续性。灾难恢复策略必须在成本、性能影响和数据丢失可能性之间达到平衡。
+ **[必需] **根据工作负载要求，为所有 ElastiCache 组件制定和记录灾难恢复策略。ElastiCache 的独特之处在于，有些使用案例是完全是临时的，不需要任何灾难恢复策略；而另一些使用案例则截然相反，需要极其稳健的灾难恢复策略。所有选项都必须针对成本优化进行权衡 – 恢复能力越高，则需要的基础设施就越多。

  了解区域级别和多区域级别上可用的灾难恢复选项。
  + 建议进行多可用区部署以防出现可用区故障。确保在多可用区架构中启用集群模式进行部署，且至少提供 3 个可用区。
  + 建议使用全局数据存储以防出现区域故障。
+ **[最佳] **为需要区域级恢复能力的工作负载启用全局数据存储。
  + 制定计划，以便在主区域出现性能下降时失效转移到辅助区域。
  + 在生产环境中进行失效转移之前，测试多区域失效转移过程。
  + 监控 `ReplicationLag` 指标，以了解失效转移事件期间数据丢失带来的潜在影响。
+ **[资源]：**
  + [缓解故障](disaster-recovery-resiliency.md#FaultTolerance)
  + [使用全局数据存储跨 AWS 区域进行复制](Redis-Global-Datastore.md)
  + [从备份还原（可选择调整集群大小](backups-restoring.md)
  + [利用多可用区最大限度减少 ElastiCache for Valkey 和 ElastiCache for Redis OSS 中的停机时间](AutoFailover.md)

## REL 4：如何有效地规划失效转移？
<a name="ReliabilityPillarREL4"></a>

**问题级简介：**启用具有自动失效转移功能的多可用区是 ElastiCache 最佳实践。某些情况下，在服务操作过程中，ElastiCache for Valkey 和 ElastiCache for Redis OSS 会取代主节点。这些情况包括计划维护事件，以及节点故障或可用区出现问题等此类不太可能发生的情况。失效转移的成功与否依赖于 ElastiCache 和您的客户端库配置。

**问题级优势：**将 ElastiCache 失效转移的最佳实践与特定的 ElastiCache 客户端库相结合，有助于您最大限度地减少失效转移事件期间的潜在停机时间。
+ **[必需] **如果禁用集群模式，请使用超时，以便客户端检测是否需要断开与旧的主节点的连接，然后使用更新后的主端点 IP 地址重新连接到新的主节点。如果启用了集群模式，则客户端库负责检测底层集群拓扑的变化。此操作通常是通过 ElastiCache 客户端库中的配置设置来实现的，该操作还允许您配置刷新的频率和方法。每个客户端库都提供自己的设置，更多详细信息可在相应的文档中找到。

  **[资源]：**
  + [利用多可用区最大限度减少 ElastiCache for Valkey 和 ElastiCache for Redis OSS 中的停机时间](AutoFailover.md)
  + 查看 ElastiCache 客户端库的最佳实践。
+ **[必需] **失效转移的成功取决于主节点和副本节点之间运行状况正常的复制环境。查看并了解 Valkey 和 Redis OSS 复制的异步性质，以及可用的 CloudWatch 指标，以便报告主节点和副本节点之间的复制延迟。对于需要更高数据安全性的使用案例，请利用 WAIT 命令强制副本在响应连接的客户端之前确认写入。

  **[资源]：**
  + [Valkey 或 Redis OSS 的指标](CacheMetrics.Redis.md)
  +  [使用 Amazon CloudWatch 监控 ElastiCache 的最佳实践](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[最佳] **在失效转移期间，使用 ElastiCache 测试失效转移 API 定期验证应用程序的响应能力。

  **[资源]：**
  + [在 ElastiCache 上测试到只读副本的自动失效转移](https://aws.amazon.com/blogs/database/testing-automatic-failover-to-a-read-replica-on-amazon-elasticache-for-redis/)
  + [测试自动失效转移](AutoFailover.md#auto-failover-test)

## REL 5：您的 ElastiCache 组件是否设计为可扩展？
<a name="ReliabilityPillarREL5"></a>

**问题级简介：**通过了解扩展能力和可用的部署拓扑，您的 ElastiCache 组件可以不断进行调整，以满足不断变化的工作负载要求。ElastiCache 提供 4 种扩展方式：横向缩减/横向扩展（横向）和纵向扩展/缩减（纵向）。

**问题级优势：**遵循 ElastiCache 部署的最佳实践可提供最大的扩展灵活性，同时还符合 Well Architected 原则，即横向扩展以最大限度地减少故障的影响。
+ **[必需] **了解启用集群模式的拓扑与禁用集群模式的拓扑之间的区别。在几乎所有情况下，均建议在启用集群模式的情况下进行部署，因为这可以不断提高可扩展性。禁用集群模式的组件通过添加只读副本进行水平扩展的能力受到限制。
+ **[必需] **了解何时以及如何扩展。
  + 要获得更多 READIOPS：添加副本
  + 要获得更多 WRITEOPS：添加分片（横向扩展）
  + 要获得更多网络 IO：使用网络优化型实例，纵向扩展
+ **[最佳] **在启用集群模式的情况下部署 ElastiCache 组件，偏向于更多、更小的节点，而不是更少、更大的节点。这可有效地限制节点故障的影响范围。
+ **[最佳] **在集群中加入副本，以增强扩展事件期间的响应能力
+ **[良好] **如果禁用了集群模式，请利用只读副本增加总体读取容量。ElastiCache 在禁用集群模式的情况下最多支持 5 个只读副本，还支持纵向扩展。
+ **[资源]：**
  + [扩缩 ElastiCache 集群](Scaling.md)
  + [在线纵向扩展](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)