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 区域中多个区域中的内存资源。