本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
亚马逊 Well-A ElastiCache rchitected 镜头可靠性支柱
主题
REL 1：您如何支持高可用性（HA）架构部署？
问题级简介：了解 Amazon 的高可用性架构 ElastiCache 将使您能够在可用性事件期间以弹性状态运行。
问题层面的好处：设计ElastiCache 集群使其能够抵御故障，可确保您的 ElastiCache 部署具有更高的可用性。
-
[必需] 确定您的 ElastiCache 集群所需的可靠性级别。不同的工作负载具有不同的弹性标准，从完全的临时工作负载到任务关键型工作负载。定义您运行的每种环境类型（例如开发、测试和生产）的需求。
缓存引擎： ElastiCache （Memcached）vs ElastiCache （Redis OSS）
-
ElastiCache (Memcached) 不提供任何复制机制，主要用于临时工作负载。
-
ElastiCache (Redis OSS) 提供的高可用性功能如下所述
-
-
[最佳] 对于需要 HA 的工作负载，请在集群模式下使用 ElastiCache (Redis OSS)，每个分片至少有两个副本，即使对于只需要一个分片的小吞吐量要求工作负载也是如此。
-
如果启用了集群模式，将自动启用多可用区。
在发生任何计划内或计划外维护以及缓解可用区故障时，多可用区通过执行从主节点到副本的自动失效转移来最大限度地减少停机时间。
-
对于分片工作负载，至少三个分片可在故障转移事件期间更快地恢复，因为 Redis OSS 集群协议要求大多数主节点都可用才能达到法定人数。
-
跨可用性设置两个或更多副本。
拥有两个副本可以提高读取可扩展性，也可以在一个副本处于维护状态的场景中提供读取可用性。
-
使用基于 Graviton2 的节点类型（大多数区域中的原定设置节点）。
Amazon ElastiCache for Redis OSS 在这些节点上增加了优化的性能。因此，您可以获得更佳的复制和同步性能，从而提高整体可用性。
-
监控并调整大小以应对预期的流量高峰：在负载过重的情况下， ElastiCache （Redis OSS）引擎可能会失去响应，从而影响可用性。
BytesUsedForCache和DatabaseMemoryUsagePercentage是衡量内存使用情况的良好指标，而则ReplicationLag是基于写入速率的复制运行状况的指标。您可以使用这些指标来触发集群扩展。 -
通过在生产失效转移事件之前使用失效转移 API 进行测试，确保客户端恢复能力。
[资源]：
-
REL 2：您是如何实现恢复点目标 (RPO) 的ElastiCache？
问题级简介：了解工作负载 RPO，为 ElastiCache 备份和恢复策略决策提供依据。
问题级优势：制定适当的 RPO 策略，可以提高灾难恢复情景下的业务连续性。设计备份和还原策略可以帮助您实现 ElastiCache 数据的恢复点目标 (RPO)。 ElastiCache (Redis OSS) 提供存储在 Amazon S3 中的快照功能以及可配置的保留策略。这些快照是在定义的备份时段内拍摄的，并由服务自动处理。如果您的工作负载需要额外的备份粒度，则可以选择每天创建多达 20 个手动备份。手动创建的备份没有服务保留策略，可以无限期保留。
-
[必需] 了解并记录 ElastiCache 部署的 RPO。
-
请注意，Memcached 不提供任何备份流程。
-
查看 ElastiCache Backup 和 Restore 功能的功能。
-
-
[最佳] 制定一个沟通良好的集群备份流程。
-
根据需要启动手动备份。
-
查看自动备份的保留策略。
-
请注意，手动备份将会无限期保留。
-
将自动备份安排在使用率比较低的时段内进行。
-
对只读副本执行备份操作，以确保将对集群性能的影响降至最低。
-
-
[良好] 利用的 ElastiCache 定时备份功能在定义的时间段内定期备份数据。
-
定期测试从备份中执行的还原。
-
-
[资源]：
REL 3：您如何支持灾难恢复（DR）要求？
问题级简介：灾难恢复是任何工作负载规划的重要方面。 ElastiCache (Redis OSS) 提供了多种选项，可根据工作负载弹性要求实现灾难恢复。借助 Amazon ElastiCache Global Datastore，您可以写入位于一个区域的 ElastiCache （Redis OSS）集群，并从另外两个跨区域副本集群中读取数据，从而实现跨区域的低延迟读取和灾难恢复。
问题级优势：了解各种灾难情景并相应进行规划可以确保业务连续性。灾难恢复策略必须在成本、性能影响和数据丢失可能性之间达到平衡。
-
[必需] 根据工作负载要求为所有 ElastiCache 组件制定并记录灾难恢复策略。 ElastiCache 的独特之处在于，有些用例完全是短暂的，不需要任何灾难恢复策略，而另一些用例则处于另一端，需要极其强大的灾难恢复策略。所有选项都必须针对成本优化进行权衡 – 恢复能力越高，则需要的基础设施就越多。
了解区域级别和多区域级别上可用的灾难恢复选项。
-
建议进行多可用区部署以防出现可用区故障。确保在多可用区架构中启用集群模式进行部署，且至少提供 3 个可用区。
-
建议使用全局数据存储以防出现区域故障。
-
-
[最佳] 为需要区域级恢复能力的工作负载启用全局数据存储。
-
制定计划，以便在主区域出现性能下降时失效转移到辅助区域。
-
在生产环境中进行失效转移之前，测试多区域失效转移过程。
-
监控
ReplicationLag指标，以了解失效转移事件期间数据丢失带来的潜在影响。
-
-
[资源]：
REL 4：如何有效地规划失效转移？
问题级简介：启用具有自动故障转移功能的多可用区是一种最佳实践。 ElastiCache 在某些情况下，作为服务操作的一部分，ElastiCache （Redis OSS）会替换主节点。这些情况包括计划维护事件，以及节点故障或可用区出现问题等此类不太可能发生的情况。成功的故障转移取决于两者 ElastiCache 以及您的客户端库配置。
问题级别的好处：将 ElastiCache 故障转移最佳实践与您的特定 ElastiCache （Redis OSS）客户端库结合使用，可帮助您最大限度地减少故障转移事件期间的潜在停机时间。
-
[必需] 如果禁用集群模式，请使用超时，以便客户端检测是否需要断开与旧的主节点的连接，然后使用更新后的主端点 IP 地址重新连接到新的主节点。如果启用了集群模式，则客户端库负责检测底层集群拓扑的变化。这通常是通过 ElastiCache (Redis OSS) 客户端库中的配置设置完成的，这些设置还允许您配置刷新频率和刷新方法。每个客户端库都提供自己的设置，更多详细信息可在相应的文档中找到。
[资源]：
-
查看您的 ElastiCache （Redis OSS）客户端库的最佳实践。
-
[必需] 失效转移的成功取决于主节点和副本节点之间运行状况正常的复制环境。查看并了解 Redis OSS 复制的异步性质，以及报告主节点和副本节点之间复制延迟的可用 CloudWatch 指标。对于需要更高数据安全性的用例，可以利用 Redis OSS WAIT 命令强制副本在响应连接的客户端之前确认写入。
[资源]：
-
[最佳] 使用 ElastiCache测试故障转移 API 定期验证应用程序在故障转移期间的响应能力。
[资源]：
REL 5：您的 ElastiCache 组件是否专为可扩展而设计？
问题级简介：通过了解扩展功能和可用的部署拓扑，您的 ElastiCache组件可以随着时间的推移进行调整以满足不断变化的工作负载要求。 ElastiCache提供 4 向缩放：入/出（水平）和向上/向下（垂直）。
问题层面的好处：遵循 ElastiCache 部署的最佳实践可以最大限度地提高扩展灵活性，并符合横向扩展以最大限度地减少故障影响的 Well Architected 原则。
-
[必需] 了解启用集群模式的拓扑与禁用集群模式的拓扑之间的区别。在几乎所有情况下，均建议在启用集群模式的情况下进行部署，因为这可以不断提高可扩展性。禁用集群模式的组件通过添加只读副本进行水平扩展的能力受到限制。
-
[必需] 了解何时以及如何扩展。
-
要获得更多 READIOPS：添加副本
-
要获得更多 WRITEOPS：添加分片（横向扩展）
-
要获得更多网络 IO：使用网络优化型实例，纵向扩展
-
-
[最佳] 在启用集群模式的情况下部署 ElastiCache 组件，偏向于更多、更小的节点，而不是更少、更大的节点。这可有效地限制节点故障的影响范围。
-
[最佳] 在集群中加入副本，以增强扩展事件期间的响应能力
-
[良好] 如果禁用了集群模式，请利用只读副本来增加总体读取容量。 ElastiCache 在集群模式下支持最多 5 个只读副本，并支持垂直扩展。
-
[资源]：