快速的未来正在您所在的城市举办的活动中。
加入我们在 Redis 发布会
分享
在 11 月 12 日星期二的早些时候，Redis DevOps 团队开始从位于亚马逊网络服务 eu-central 区域（德国法兰克福）的生产集群中收到突发警报。经过进一步检查，他们意识到 AWS 的 eu-central-1 数据中心发生了重大中断，这在 AWS 状态页面 上得到了证实，并最终 在新闻中报道
云中断对我们来说并不新鲜。自 2013 年初以来，我们一直在运行生产 Redis 集群，在此期间，我们经历了 3,000 多次实例故障和 100 多次数据中心完全中断。我们非常感谢云提供商为稳定其基础设施所付出的辛勤努力，但我们也知道故障是不可避免的。这就是为什么我们在过去几年中投入了大量工程资源，以确保我们的 Redis 企业云服务 能够提供行业领先的五九（99.999%）可用性。
在分享有关我们如何克服中断的详细信息之前，让我们快速了解一下 Redis 企业云架构。该服务在所有三大公共云（AWS、Microsoft Azure 和 Google Cloud）和区域中部署和管理多个 Redis 企业集群。每个 Redis 企业集群 以多租户和隔离的方式管理各种配置的多个数据库（例如：单实例 Redis、高可用性 Redis、仅主节点 Redis 集群和高可用性 Redis 集群）。我们喜欢将其视为 Redis 数据库的编排平台。这意味着我们其中一个集群的故障可能会影响我们数百甚至数千个客户的数据库。
考虑到利害关系，我们推广多 AZ（多个可用区）数据库配置，以帮助客户避免因基础设施中断（如星期二发生的情况）导致的数据库故障。
在这种特定情况下，尽管我们所有 AWS eu-central 集群都受到了影响，但我们所有客户都部署在多个可用区中，因此中断并未影响集群的操作和可用性——即使是在其中一个集群中，15 个节点集群中的 5 个节点出现故障！此外，数百次自动故障转移事件顺利完成，没有任何数据丢失（当然），也没有出现任何紧急支持票。一些用户抱怨执行一些管理操作花费的时间比预期要长，但这在发生此类中断时并不奇怪。
这怎么可能？以下是 Redis 企业版在多 AZ 配置中运行的原理
1. 内存中复制。所有 Redis 企业版数据库都使用纯内存中复制（我们回馈到 OSS 项目的功能，很快将成为 Redis 6.0 的一部分）。内存中复制使复制速度提高一倍，从而最大程度地减少 Redis 暴露于双重故障事件的时间。
2. 相同数据集（哈希槽）的主节点和副本实例部署在不同的节点上。在多 AZ 部署中，它们也部署在不同的可用区中。
3. 每个集群节点都连接到外部持久性内存，以在集群完全故障的情况下快速恢复。（幸运的是，这次没有发生这种情况。）
4. 我们的集群始终包含奇数个节点；这种设计使我们能够处理脑裂情况，就像网络分割事件中一样。
5. 出于同样的原因，在多 AZ 配置中，我们的集群部署在奇数个区域中。
6. 我们确保每个区域中部署的节点数量始终小于集群节点数量的一半。这保证了单区域故障不会导致仲裁丢失。
典型的 Redis 企业云多 AZ 配置可能如下所示
每个现代数据库都应提供多 AZ 功能，但这还不够以保证 99.999% 的可用性。五九可用性，或每月不超过 26.3 秒的停机时间，无法在没有真正的主动-主动多区域部署的情况下实现，这种部署允许客户立即从区域完全故障中恢复。下图总结了我们为 Redis 企业云提供的 SLA 类型
当我们辛辛苦苦构建的功能在极端和意外的生产环境下按预期工作时，总令人欣慰。此事件再次证明了 Redis 企业版如何可以用作关键任务用例的主数据库，特别是对于需要以极高吞吐量实现亚毫秒级延迟的客户。
