在11月12日星期二的早些时候，Redis DevOps团队开始收到来自我们位于亚马逊网络服务欧盟中部地区(德国法兰克福)的生产集群的突发警报。经过进一步的检查，他们意识到AWS的eu-central-1数据中心发生了严重的宕机，这一情况在2010年被证实AWS状态页,并最终媒体报道：
云中断对我们来说并不新鲜。自2013年初以来，我们一直在运行Redis生产集群，在此期间，我们经历了3000多个实例故障和100多个完整的数据中心中断。我们非常感谢云提供商为稳定其基础设施所做的努力，但我们也知道失败是不可避免的。这就是为什么我们多年来投入了大量的工程资源，以确保我们的万博体育彩Redis企业云服务旨在提供业界领先的五-九(99.999%)可用性。
在分享我们如何克服宕机的细节之前，让我们快速看一下Redis的企业云架构。万博体育彩该服务在所有三个主要的公共云(AWS、Microsoft Azure和谷歌云)和区万博体育彩域上部署和管理多个Redis企业集群。每一个万博体育彩复述,企业集群支持多租户、隔离管理多种配置的数据库(例如:单实例、高可用性、主用集群、高可用性集群等)。我们喜欢把它看作是Redis数据库的编排平台。这意味着一个集群中的故障可能会影响数百甚至数千个客户的数据库。
考虑到风险，我们提倡多az(多个可用分区)数据库配置，以帮助客户避免由于基础设施中断(比如周二发生的情况)而导致的数据库故障。
在这个特定的案例中，尽管我们所有的AWS eu-central集群都受到了影响，但我们所有的客户都部署在多个可用性区域，因此宕机不会影响集群的操作和可用性——即使在其中一个集群中，15个节点中的5个集群宕机!此外，数百个自动故障转移事件顺利进行，没有任何数据丢失(当然)，也没有任何紧急支持请求。一些用户抱怨说，执行一些管理操作花费的时间比预期的要长，但在这样的停机期间，这并不奇怪。
这怎么可能?以下是在多az配置下运行Redis Enterprise的原则:万博体育彩
1.内存复制。所有的R万博体育彩edis企业数据库使用纯内存复制(这是我们贡献给OSS项目的一个特性，很快将成为Redis 6.0的一部分)。内存内复制使复制速度提高了一倍，这使Redis暴露于双重故障事件的时间最小化。
2.同一数据集(hash-slot)的主实例和副本实例部署在不同的节点上。在多az部署中，它们也部署在不同的可用分区中。
3.每个集群节点都连接到外部持久内存，以便在整个集群发生故障时能够快速恢复。(幸运的是，这次没有发生这种情况。)
4.我们的集群总是包含不均匀的节点数量;这种设计允许我们处理分裂的情况，如在网络分裂事件的情况下。
5.出于同样的原因，在多az配置中，我们的集群部署在不均匀数量的分区上。
6.我们确保每个区域中部署的节点数量始终少于集群节点数量的一半。这保证了单个az故障不会导致quorum丢失。
一个典型的Redis万博体育彩企业云多az配置可能是这样的:
每个现代数据库都应该提供多az功能，但是仅仅这样还不足以保证99.999%的可用性。如果没有真正的双活多区域部署(允许客户立即从完全区域故障中恢复)，就无法实现5 - 9的可用性，或每月停机时间少于26.3秒。下图总结了……的类型SLA我们提供与Redis企业云万博体育彩：
当我们如此努力地构建的功能在极端和意外的生产条件下实际工作时，总是令人满意的。这个事件代表了另一个例子，Redis企业可以作为主数据库的关键任务的情况下，特别是客户需要亚毫秒级万博体育彩延迟在极高的吞吐量。
万博app手机客户端下载