AWS 中断与内存中数据存储

据亚马逊称，在 2012 年 6 月期间，AWS 的 us-east-1 区域第二次发生故障，这次是由于极端天气条件导致的停电。对于使用 Memcached 等内存中数据存储或 AWS ElastiCache 等服务的人来说，这种停电的结果是丢失整个 Memcached 数据集。这意味着所有数据库查询现在都导向您的主数据库，而您的主数据库通常不是为承受此类负载而构建的。这意味着您的应用程序可能会遭受显著的性能下降，在极端情况下甚至可能崩溃。从 Memcached 故障中恢复可能需要数天甚至数周。此外，许多当今的应用程序和开发平台，如 Magento、WordPress、Drupal 和 Django，将用户会话存储在 Memcached 中。丢失此类数据通常意味着强制所有用户立即注销，如果您运营的是电子商务网站，则会清空所有用户的购物车。这两种情况都可能对您的业务产生不利影响。在 Garantia Data，我们对 Memcached 和 Redis 等内存中 NoSQL 数据存储的运营采用了不同的方法，确保数据集永不丢失，同时保持这些极速平台的高吞吐量和低延迟。我们内置的复制和自动故障转移流程帮助我们在 6 月 15 日的 AWS 中断中实现了零停机！——将受影响区域中所有故障节点的内存数据集切换到我们集群的健康节点。尽管复制是从节点故障事件中恢复的一种非常有效的方法，但最近 6 月 30 日的 AWS 停电同时影响了我们服务的多个集群节点。然而，得益于我们强大的数据持久化机制，我们得以从本次故障中恢复，且未遭受损失。我们的用户使用仅追加文件 (AOF) 或快照方法，在持久性存储 (EBS) 中维护其数据集的副本。顺便说一下，此功能也不会带来任何应用程序性能下降。我们还允许每日 S3 备份，事实证明，在 EBS 卷损坏的情况下（如最近的 AWS 中断），这非常有效。总而言之——我们强大的数据持久化机制使我们能够成功地从 6 月 30 日的 AWS 中断中恢复所有用户的整个数据集！未来改进

• 我们正在努力为我们的恢复流程添加自动化工具，以缩短从致命区域故障中恢复所需的时间。
• 我们计划在未来几个月内提供多区域复制功能。这将允许我们的用户以高可用和一致的方式，从 AWS 区域的多个可用区访问他们的内存资源。