Redis 8 已发布——且它是开源的
了解更多
分享
您可能已经听说了 AWS 上周日下午太平洋时间中午左右发生的故障。亚马逊 forest 云中最繁忙的数据区域之一发生的那个“轻微”的网络兼存储问题的砰砰声被清晰地听到。甚至在那棵倒下的 zone 树的叶子落地之前，关于一些知名社交品牌（例如 Instagram、Vine 和 IFTTT）崩溃的报告就开始传来了。
像往常一样，AWS 没有透露事件影响的全部范围，但可以合理推断还有其他（尽管规模较小）的受害者。我们的 Redis Cloud 和 Memcached Cloud 服务使用了该区域的资源，并且我们在此管理着相当数量的大型集群。鉴于我们复制和持久的内存数据库的特性，我们大量使用了网络和存储，因此在听到第一个不祥的裂开声时，我们的仪表盘自然地闪烁着刺眼的红色。
从我们在环境中监测到的损坏程度来看，我们认为该区域 15-30% 的服务可能受到了此次事件的影响。即使在网络开始劣化之后，我们的系统也幸好能够承受住中断。我们的复制流大部分时间没有延迟，响应延迟的影响相对较小。
我们的非多可用区 (non-Multi-AZ) 实例的可用性在一段时间内看起来有些不稳定，但我们还是挺住了。但就在一切看起来最坏的时候已经过去、系统震荡正在平息之际，随着存储的加速衰退，我们经历了性能的急剧下降。
悬念。
尽管乍听起来有些反直觉，但内存数据库确实使用存储。然而，它们只用于存储数据，而不是像基于磁盘的数据库那样从中读取和写入数据。
将数据写入磁盘赋予了内存数据库持久性——这是一个非常理想的特性，在从系统崩溃中恢复时非常有用，但那是另一回事了。然而，这也意味着当存储变得不可用时，数据库无法确保数据的持久性。它仍然可以提供读取请求，但在大多数情况下，一个只读数据库就像自行车上的鱼一样无用。
这就是为什么大多数内存数据库（包括 Redis）被设计成在没有可访问存储时停止运行的原因。
随着多个节点存储同时出现故障，我们的系统做了它们唯一能做的事情：绕过故障来自我恢复并保持服务运行。
受影响的节点继续为非持久性 Redis Cloud 实例提供服务，同时对持久性实例采取了立即行动。支持持久性的 Redis Cloud 实例在对我们的服务造成任何中断之前，被迅速迁移到未受影响的服务器和存储资源上。诚然，我们在将数据从一个地方移动到另一个地方时给网络和存储带来的额外负载，并非是为了解决正在出现的问题，而是为了迅速撤退到附近的避难所。
尘埃落定后，我们迅速对用户进行了调查，欣慰地得知在此期间没有人遇到我们的服务问题（尽管我们的日志看起来就像是精神变态的斧头杀手所为）。当然，如果这次故障稍严重一些，情况可能会有所不同。
我们很高兴情况并非如此，并且通过真实的证据验证了为动态稳定性设计的系统是如何应对其被设计来应对的挑战的。
