AWS 上用于 SNS 通知的多区域架构

Posted 2023-03-04

【中文标题】AWS 上用于 SNS 通知的多区域架构

【英文标题】：Multi Region Architecture on AWS for SNS notifications

【发布时间】：2019-04-05 08:16:37

【问题描述】：

我们正在为我们的应用程序尝试多区域架构。被多个客户使用。

我们正在使用 aws 来复制数据库（s3 和 dynamodb），它解决了数据可用性问题。

每当有任何数据更改时，我们都会使用 SNS 通知我们的客户，但我找不到任何好的跨区域消息复制模式。

以下是我们必须牢记的一些注意事项/要求

客户端应该能够获得所有通知，即使它们只在一个区域内。

即使一个区域出现故障，应用程序也应该继续工作。如果可能，可以在区域出现时重播消息。

以下是一些我们想到的优缺点方法。

EC2 服务器写入两个区域

优点

一个。要求 1 很容易满足。

缺点。

一个。不确定这是否可行，因为没有文档建议这样做。

b.如果某个区域出现故障，将无法重播消息。

c。写入两个区域的延迟延迟。

有一个 lambda 函数来写入这两个区域。由于 lambda 函数可以订阅跨区域的 sqs 和 sns。我们可以在两个区域中都有一个 lambda 函数，监听另一个区域的 sns/sqs，然后写入自己区域的 sns。

优点：

一个。满足要求 1。

b. 如果我们使用sqs而不是sns，则满足要求2，如果区域关闭，消息将在队列中保留一段时间，并且每当区域出现时将重播消息。跨区域sqs订阅不是可能而且 lambda 函数必须订阅 sns。

缺点：

一个。跨区域权限是指在cloudformation中硬编码，不确定cloudformation是否支持从其他区域导入。

b. lambda 函数的成本。 （虽然它会很小）

我们没有写入 sns，而是写入 dynamodb 并使用 dynamodb 全局表和流在两个区域中发送通知。

优点

一个。满足要求 1。

b.要求 2 已解决，因为 dynamodb 复制将负责复制消息。

缺点。

一个。昂贵的解决方案。

您能否建议我是否遗漏了什么或其他一些我们应该考虑的模式？

看了以上可能的方法，我倾向于方法2，

【参考方案1】：

我们最终使用这种方法解决了它

应用程序将消息写入 SQS。

一个 lambda 函数订阅了队列。

Lambda 函数写入区域的两个 sns。

通过这种方式，我们可以在发送消息之前引入延迟和一些预处理。然而，IMO 最好的解决方案是使用 dynamodb 流来生成消息（不是新的 dynamodb 表，而是来自我们正在写入数据的表），因为这意味着当我们在一个特定区域发送消息时，数据已经被复制了。