快速的未来即将在您所在的城市举行活动。
加入我们参加 Redis 发布会
分享
您可能已经听说上周日太平洋时间中午左右 AWS 出现了宕机。亚马逊森林云中最繁忙的数据区域之一发生的“轻微”的网络和存储问题的巨响清晰可闻。甚至在这棵倒下的区域树的叶子接触到地面之前，关于一些知名社交品牌（例如Instagram、Vine 和 IFTTT）崩溃的消息就开始传来了。
像往常一样，AWS 尚未公布该事件影响的全部范围，但可以肯定的是，还有其他规模较小的受害者。我们的 Redis 云和 Memcached 云服务使用来自该区域的资源，我们在这个区域中管理着许多相当大的集群。鉴于我们复制和持久化内存数据库的性质，我们大量使用网络和存储，因此当第一个不祥的裂解声响起时，我们的仪表板自然就亮起了鲜艳的红色。
根据我们在环境中监控到的损害程度，我们认为该区域 15% 到 30% 的服务可能受到了该事件的影响。即使在网络开始降级之后，我们的系统也幸运地能够经受住中断。我们的复制流在大多数情况下没有出现延迟，响应延迟的影响相对较小。
我们的非多可用区实例的可用性有一段时间看起来不太稳定，但我们坚持了下来。但就在看起来最糟糕的时刻已经过去，震动开始消退时，我们经历了存储加速下降带来的性能急剧下降。
悬念。
虽然乍一看有点违反直觉，但内存数据库确实使用存储。但是，它们只使用存储来存储数据，而不是像基于磁盘的数据库那样从磁盘读写数据。
将数据写入磁盘使内存数据库具有持久性——这是一个非常理想的特性，在从崩溃中恢复时非常有用，但那是另一个故事。但是，这也意味着当存储变得不可用时，数据库无法确保数据的持久性。它仍然可以处理读取请求，但在大多数情况下，只读数据库就像一辆自行车上的鱼。
这就是为什么大多数内存数据库（包括 Redis）在没有可访问的存储的情况下都设计为停止运行。
由于存储在多个节点上同时出现故障，我们的系统只能做一件事：绕过故障，自行恢复，并保持服务的运行。
受影响的节点继续为非持久化 Redis 云实例提供服务，同时对持久化实例采取了紧急措施。在对服务造成任何中断之前，已启用持久化的 Redis 云实例被迅速迁移到不受影响的服务器和存储资源。当然，我们在将数据从一个地方移动到另一个地方时对网络和存储施加的额外负载并非旨在解决正在发生的问题，而是旨在迅速撤回到附近的庇护所。
尘埃落定后，我们对用户进行了一次快速调查，并松了一口气地得知，在此期间，没有任何用户遇到过我们服务的任何问题（尽管我们的日志看起来像是精神病杀人狂的杰作）。当然，如果这次宕机稍微严重一些，情况可能会有所不同。
我们很高兴这种情况没有发生，并且感到很欣慰，因为我们获得了现实生活中如何应对其构建目标的挑战的动态稳定性系统的证明。
