本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
缓解故障
在规划 Amazon ElastiCache 实施时，您应做好计划，尽量减少故障对应用程序和数据的影响。本部分中的主题涵盖了可用来防止应用程序和数据出现故障的方法。
缓解运行 Memcached 时发生的故障
运行 Memcached 引擎时，您有以下选择来最大程度地减小故障的影响。故障缓解计划中有两类需要解决的故障：节点故障和可用区故障。
缓解节点故障
无服务器缓存使用复制的多可用区架构，自动缓解节点故障，因此节点故障对您的应用程序是透明的。在自行设计的集群中，要缓解节点故障的影响，请将缓存数据分布到多个节点。由于自行设计的集群不支持复制，因此节点故障始终会导致集群中的一些数据丢失。
在创建 Memcached 集群时，您可以创建包含 1 到 60 个节点的集群，也可以根据特殊要求创建更多节点。跨更多节点对数据进行分区意味着，在节点出现故障时丢失的数据更少。例如，如果您跨 10 个节点对数据进行分区，则任一节点均可存储您的约 10% 的缓存数据。在此情况下，在创建和预配置替换节点时，节点故障会导致丢失约 10% 的需替换的缓存数据。如果在 3 个较大的节点中对相同的数据进行缓存，则节点故障将导致丢失约 33% 的缓存数据。
如果您在 Memcached 集群中需要超过 60 个节点，或者一个 Amazon 区域中总共需要超过 300 个节点，请填写 https://aws.amazon.com/contact-us/elasticache-node-limit-request/
有关指定 Memcached 集群中的节点数的信息，请参阅创建 Memcached 集群（控制台）。
缓解可用区故障
无服务器缓存使用复制的多可用区架构，自动缓解可用区故障，因此可用区故障对您的应用程序是透明的。
要缓解自行设计集群中可用区故障的影响，请将节点置于尽可能多的可用区中。在出现极少发生的可用区故障时，您将丢失已在该可用区中缓存的数据，而不会丢失在其他可用区中缓存的数据。
为何要使用如此多的节点？
如果我的区域只有 3 个可用区，既然在可用区出现故障时，我会丢失约三分之一的数据，那么为何我需要 3 个以上的节点？
这个问题问得很好。请记住，我们正在尝试缓解两种不同类型的故障，即节点故障和可用区故障。您说得对，如果您的数据跨可用区分布且其中一个区域发生故障，则无论您拥有多少个节点，都只会丢失该可用区中缓存的数据。但是，如果节点出现故障，则拥有更多节点将减少丢失的数据的比例。
没有用于确定集群中拥有的节点数的“神奇公式”。您必须权衡数据丢失的影响、发生故障的可能性与成本，并得出您自己的结论。
有关指定 Memcached 集群中的节点数的信息，请参阅创建 Memcached 集群（控制台）。
有关区域和可用区的更多信息，请参阅区域和可用区。
建议
我们建议对自行设计的集群创建无服务器缓存，因为这样您无需额外配置即可自动获得更好的容错能力。但是，在创建自行设计集群时，您需要规划两种类型的故障：单个节点故障和广泛的可用区故障。最佳的故障缓解计划将解决这两种故障。
尽可能减少节点故障的影响
如果您正在运行 Memcached 并且正在跨节点对数据进行分区，在任一节点出现故障的情况下，您使用的节点越多，丢失的数据就越少。
最大程度地减小可用区故障的影响
要最大程度地减小可用区故障的影响，建议您在提供的不同可用区内启动节点。跨可用区均匀分布节点将最大程度地减小极少发生的可用区故障的影响。对于无服务器缓存，此过程自动完成。