本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Amazon ElastiCache 中的恢复能力
Amazon全球基础架构围绕Amazon区域和可用区构建。Amazon区域提供多个在物理上独立且隔离的可用区，这些可用区通过延迟低、吞吐量高且冗余性高的网络连接在一起。利用可用区，您可以设计和操作在可用区之间无中断地自动实现故障转移的应用程序和数据库。与传统的单个或多个数据中心基础架构相比，可用区具有更高的可用性、容错性和可扩展性。
有关 Amazon 区域和可用区的更多信息，请参阅 Amazon 全球基础架构
除 Amazon 全球基础设施外，Amazon ElastiCache 还提供多种功能，以帮助支持您的数据恢复能力和备份需求。
主题
缓解故障
规划 Amazon ElastiCache 实施时，您应做好计划以最大程度地减小故障对应用程序和数据产生的影响。本部分中的主题涵盖了可用来防止应用程序和数据出现故障的方法。
缓解运行 Memcached 时发生的故障
运行 Memcached 引擎时，您有以下选择来最大程度地减小故障的影响。故障缓解计划中有两类需要解决的故障：节点故障和可用区故障。
缓解节点故障
无服务器缓存使用复制的多可用区架构，自动缓解节点故障，因此节点故障对您的应用程序是透明的。在自行设计的集群中，要缓解节点故障的影响，请将缓存数据分布到多个节点。由于自行设计的集群不支持复制，因此节点故障始终会导致集群中的一些数据丢失。
在创建 Memcached 集群时，您可以创建具有 1 到 60 个或以上（根据特殊请求）的节点的集群。跨更多节点对数据进行分区意味着，在节点出现故障时丢失的数据更少。例如，如果您跨 10 个节点对数据进行分区，则任一节点均可存储您的约 10% 的缓存数据。在此情况下，在创建和预配置替换节点时，节点故障会导致丢失约 10% 的需替换的缓存数据。如果在 3 个较大的节点中对相同的数据进行缓存，则节点故障将导致丢失约 33% 的缓存数据。
有关指定 Memcached 集群中的节点数的信息，请参阅创建 Memcached 集群（控制台）。
缓解可用区故障
无服务器缓存使用复制的多可用区架构，自动缓解可用区故障，因此可用区故障对您的应用程序是透明的。
要缓解自行设计集群中可用区故障的影响，请将节点置于尽可能多的可用区中。在出现极少发生的可用区故障时，您将丢失已在该可用区中缓存的数据，而不会丢失在其他可用区中缓存的数据。
为何要使用如此多的节点？
如果我的区域只有 3 个可用区，既然在可用区出现故障时，我会丢失约三分之一的数据，那么为何我需要 3 个以上的节点？
这个问题问得很好。请记住，我们正在尝试缓解两种不同类型的故障，即节点故障和可用区故障。您说得对，如果您的数据跨可用区分布且其中一个区域发生故障，则无论您拥有多少个节点，都只会丢失该可用区中缓存的数据。但是，如果节点出现故障，则拥有更多节点将减少丢失的数据的比例。
没有用于确定集群中拥有的节点数的“神奇公式”。您必须权衡数据丢失的影响、发生故障的可能性与成本，并得出您自己的结论。
有关指定 Memcached 集群中的节点数的信息，请参阅创建 Memcached 集群（控制台）。
有关区域和可用区的更多信息，请参阅区域和可用区。
缓解运行 Valkey 或 Redis OSS 时发生的故障
在运行 Valkey 或 Redis OSS 引擎时，您可以使用以下选项将节点或可用区故障的影响降至最低。
缓解节点故障
无服务器缓存使用多可用区架构，自动缓解节点故障，因此节点故障对您的应用程序是透明的。自行设计集群必须得到妥善配置，以缓解单个节点出现故障的情况。
要缓解自行设计集群中 Valkey 或 Redis OSS 节点故障的影响，您有以下选择：
缓解故障：Valkey 或 Redis OSS 复制组
Valkey 或 Redis OSS 复制组由一个主节点（应用程序可以从中读取和写入数据）和 1 到 5 个只读副本节点组成。在向主节点写入数据时，也会在只读副本节点上异步更新此数据。
在只读副本发生故障的情况下
ElastiCache 会检测发生故障的只读副本。
ElastiCache 会使发生故障的节点离线。
ElastiCache 会在同一可用区中启动和预置替换节点。
新节点与主节点同步。
在此期间，应用程序可使用其他节点继续读取和写入。
Valkey 或 Redis OSS 多可用区
您可以在 Valkey 或 Redis OSS 复制组上启用多可用区。无论是否启用多可用区，都将自动检测并替换发生故障的主节点。执行此操作的方式因是否启用多可用区而异。
启用多可用区时
ElastiCache 会检测主节点故障。
ElastiCache 将复制滞后最低的只读副本节点提升为主节点。
其他副本将与新的主节点同步。
ElastiCache 在发生故障的主集群的可用区中启动只读副本。
新节点将与新提升的主节点同步。
故障转移到副本节点的速度通常比创建并预置新主节点的速度要快。这意味着，与未启用多可用区的情况相比，您的应用程序可更快地恢复对主节点的写入。
有关更多信息，请参阅 使用 Valke ElastiCache y 和 Redis 的多可用区，最大限度地减少停机时间 OSS。
禁用多可用区时
ElastiCache 会检测主要故障。
ElastiCache 将主节点脱机。
ElastiCache 创建和预置新的主节点以替换发生故障的主节点。
ElastiCache 将新的主节点与现有副本之一同步。
同步完成时，新节点将发挥集群主节点的功能。
在此过程的步骤 1 到 4 中，您的应用程序无法写入主节点。不过，您的应用程序会继续从副本节点进行读取。
要提供额外保护，建议您启动在不同可用区 (AZ) 的复制组中的节点。如果这样做，可用区故障将仅影响该可用区中的节点，而不会影响其他节点。
有关更多信息，请参阅 使用复制组时的高可用性。
缓解可用区故障
无服务器缓存使用复制的多可用区架构，自动缓解可用区故障，因此可用区故障对您的应用程序是透明的。
要缓解自行设计集群中可用区故障的影响，对于每个分片，请将节点置于尽可能多的可用区中。
无论您的一个分片有多少个节点，如果所有这些节点都位于相同的可用区内，则该可用区的灾难性故障会导致您丢失分片的所有数据。但是，如果您将节点置于多个可用区内，则任一可用区的故障只会导致您丢失该可用区内的节点。
只要您丢失节点，就会导致性能下降，因为现在共享读取操作的节点更少了。在替换节点之前，性能下降将继续。
有关为 Valkey 或 Redis OSS 节点指定可用区的信息，请参阅创建 Valkey（已禁用集群模式）集群（控制台）。
有关区域和可用区的更多信息，请参阅为以下对象选择区域和可用区 ElastiCache。
建议
我们建议对自行设计的集群创建无服务器缓存，因为这样您无需额外配置即可自动获得更好的容错能力。但是，在创建自行设计集群时，您需要规划两种类型的故障：单个节点故障和广泛的可用区故障。最佳的故障缓解计划将解决这两种故障。
尽可能减少节点故障的影响
在使用 Valkey 或 Redis OSS 时，为了尽可能减少节点故障的影响，我们建议您的实施在每个分片中使用多个节点，并将节点分布在多个可用区中。对于无服务器缓存，此过程自动完成。
对于 Valkey 或 Redis OSS 自行设计的集群，我们建议您在复制组上启用多可用区，这样在主节点出现故障时，ElastiCache 会自动失效转移到副本。
如果您正在运行 Memcached 并且正在跨节点对数据进行分区，在任一节点出现故障的情况下，您使用的节点越多，丢失的数据就越少。
最大程度地减小可用区故障的影响
要最大程度地减小可用区故障的影响，建议您在提供的不同可用区内启动节点。跨可用区均匀分布节点将最大程度地减小极少发生的可用区故障的影响。对于无服务器缓存，此过程自动完成。
其他预防措施
如果您正在运行 Valkey 或 Redis OSS，那么除了上述措施外，我们还建议您定期对集群进行备份。备份（快照）会创建一个 .rdb 文件，在出现故障或损坏时，可使用此文件还原缓存。有关更多信息，请参阅 快照和还原。