搜索

我们刚刚宣布为 Garantia Data 的 Redis 和 Memcached 云推出多个可用区域。要了解我们的多可用区域解决方案的工作原理，请继续阅读。可用区域用于将云数据中心的物理结构（也称为区域）分割成独立的部分，以限制重大灾难的影响。现代高可用性实践使用多个可用区域，从中运行应用程序的多个实例。这样一来，单个区域发生故障不会阻止该应用程序从幸存区域运行。根据希望“区域化”的设置的实际性质，实际实现所需的工作量范围从极易到极难。典型的应用程序通常是无状态引擎，因此从多个区域运行它基本上无需费力。另一方面，数据存储几乎总是状态化的，因此需要更难实现的某些形式的一致性。对于内存中数据存储，考虑到主存储的易失性和显著更高的更新速率，该挑战更大。

以下说明与我们的 Redis 多可用区域解决方案相关，但它也适用于我们的 Memcached 多可用区域解决方案。下图显示了典型的多可用区域环境。

如你所见，在正常状态下，应用程序的实例要么从区域 A 运行，要么从 A 和 B 运行。但是，数据存储仅存在于区域 A，用于为两个区域中的应用程序实例提供服务。这意味着如果区域 A 发生故障，则数据存储可能变得不可用，从而使区域 B 中的幸存应用程序实例没有数据。在我们的多可用区域解决方案中，数据存储从区域 A 复制到区域 B，如此处所示

通过我们的多可用区域复制，活动的 datastore 仍保留在区域 A 中。区域 B 的副本仅在发生更改时更新，且在没有区域故障时一直处于待机模式。如果区域 A 发生故障，区域 B 的待机副本将自动转换为活动状态，应用程序会切换到它，如下所示：这能让应用程序在发生重大故障事件时仍能不间断地继续运营。切换到区域 B 的 datastore 副本的过程完全由外部管理和执行，因此不需要任何代码/配置更改，只需要更新 datastore 的 DNS 记录，其 URL 甚至依然不变。切换到区域 B 的环境将继续为应用程序提供服务，与 datastore 重新建立连接带来的性能下降（如有）极其微小且暂时。稍后某个时候，云基础架构提供商将恢复区域 A。根据我们的多可用区域解决方案，区域 A 一旦能再次使用，将重建它以恢复多可用区域部署，以应对下一次故障。通常，应用程序服务器将首先在恢复的区域中启动，并将连接到区域 B 中当前处于活动状态的 datastore 副本。同样，客户端不需要任何修改，因为 datastore 保留了它的 URL

过了一会儿，区域 A 中 datastore 的新待机副本将完成与活动副本的同步，且复制流将从区域 B 流向区域 A。在该阶段，设置将完全恢复为多可用区域、能抵御区域故障的状态，如下所示

以下是一些挑战，当我们准备我们的服务以支持 Redis 和 Memcached 的多个可用区域时，Garantia Data 团队不得不解决这些挑战

• 区分一般的网络分割和真正的区域故障——由于前者在不同区域中要常见得多，我们开发了一种专门的闲话机制来正确识别情况和采取适当的措施。我们还设计了服务拓扑以使在真正的区域故障中更容易避免分割
• 在分割条件下确保数据一致性
• 通过拥塞的区域间网络链路复制 datastore
• 将复制数据集之间的差距控制在最小程度

所有这些辛勤工作的好处现在对你而言唾手可得，设置和易用性与我们的任何其他计划一样简单。它能够确保下次可用区域瘫痪的灾难发生时，你的数据集将被安全地保护起来，不受损害，同时保持完全可用。要开始对 Redis 和 Memcached 云使用多个可用区域，下次启动新的 Redis 数据库时只需选中“多可用区域部署”复选框即可。我们针对数据集的多可用区域计划现已在 AWS 的 us-east 数据区域提供，我们准备在未来几个月内为更多区域、云和提供商添加计划。