现已推出：跨多个可用区的 Redis 和 Memcached Cloud

我们刚刚宣布 Garantia Data 推出了适用于 Redis 和 Memcached Cloud 的多可用区功能。想了解我们的多可用区解决方案如何工作，请继续阅读。可用区用于将云数据中心（亦称区域）的物理结构分割成独立部分，以分隔重大灾难的影响范围。现代高可用性实践使用多个可用区来运行应用程序的多个实例。这样做是为了确保单个可用区发生故障时，应用程序能够继续在幸存的可用区中运行。根据您想要“分区”设置的实际性质，实现所需的工作量从微不足道到极其困难不等。典型的应用程序通常是无状态引擎，因此从多个可用区运行几乎不需要什么工作。另一方面，数据存储几乎总是有状态的，因此需要某种形式的一致性，这更难实现。对于内存数据存储，考虑到主存储的易失性和显著更高的更新率，挑战更大。

以下描述与我们的 Redis 多可用区解决方案有关，但也适用于我们的 Memcached 多可用区解决方案。典型的多可用区环境如下图所示。

可以看出，在正常状态下，应用程序实例要么从可用区 A 运行，要么从 A 和 B 两者都运行。然而，数据存储仅存在于可用区 A 中，用于服务两个可用区中的应用程序实例。这意味着如果可用区 A 发生故障，数据存储可能会变得不可用，导致可用区 B 中幸存的应用程序实例无法获取其数据。在我们的多可用区解决方案中， 数据存储从可用区 A 复制到可用区 B，如下图所示

通过我们的多可用区复制功能，主数据存储保留在可用区 A 中。可用区 B 的副本仅通过更改进行更新，并在没有可用区故障时保持备用模式。如果可用区 A 发生故障，可用区 B 的备用副本会自动提升为活动状态，并且应用程序会故障转移到该副本，如下所示：这使得应用程序能够在发生重大故障事件时继续不间断地运行。故障转移到可用区 B 的数据存储副本完全由外部管理和执行，与您的应用程序无关，因此无需进行代码/配置更改，并且通过更新数据存储的 DNS 记录，其 URL 甚至保持不变。故障转移后的可用区 B 环境将继续为应用程序流量提供服务，由于重新建立与数据存储的连接，性能下降是最小且暂时的，如果发生的话。在稍后的某个时间点，可用区 A 很可能被云基础设施提供商恢复。根据我们的多可用区解决方案，一旦可用区 A 再次可用，它将被重建以恢复多可用区部署，为下一次故障做准备。通常，应用程序服务器将首先在恢复的可用区中启动，并连接到可用区 B 中现在的主数据存储副本。同样，客户端无需进行任何修改，因为数据存储保留了其 URL。

稍后，可用区 A 中数据存储的新备用副本将完成与主副本的同步，并开始从可用区 B 到 A 的复制流。在此阶段，设置将完全恢复到其多可用区、具备区域故障恢复能力的状态，如下图所示

以下是 Garantia Data 团队在准备支持 Redis 和 Memcached 的多可用区服务时必须解决的一些挑战

• 区分普通的网络分区和真实的区域故障——由于前者在可用区之间更为常见，我们开发了一种专门的 gossip 机制来正确识别情况并采取适当行动。我们还设计了服务的拓扑结构，以便在实际区域故障情况下更容易避免分区。
• 在分区条件下确保数据一致性
• 在拥塞的可用区间网络链路上复制数据存储
• 尽量减少复制数据集之间的差距

我们辛勤工作的所有成果现已向您提供，其设置和易用性与我们的其他任何计划一样简单。它保证了下次可用区发生灾难性故障时，您的数据集将安全地保存在受保护的地方，同时保持完全可用。要开始在您的 Redis 和 Memcached Cloud 中使用多可用区功能，只需在下次启动新的 Redis DB 或 Memcached Bucket 时选中“多可用区部署”复选框即可。我们针对数据集的多可用区计划现已在 AWS 的美国东部数据区域提供，我们计划在未来几个月内增加更多区域、云和提供商的计划。