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

Question

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

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

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

这里有一些consideration/requirements我们必须牢记

1. 客户端应该能够收到所有通知，即使他们只在一个区域。

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

以下是我们想到的一些有利有弊的方法。

1. EC2 服务器写入两个区域

   优点

   一个。条件一很容易满足。

   缺点

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

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

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

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

   优点：

   一个。需求1已解决。

   b。 如果我们使用 sqs 而不是 sns，则需求 2 得到解决，如果区域关闭，消息将在队列中保留一段时间，并且只要区域出现，消息就会重播。 跨区域 ss无法订阅，lambda 函数必须订阅 sns。

   缺点：

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

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

3. 我们不写入 sns，而是写入 dynamodb 并使用 dynamodb 全局 table 和流在两个区域发送通知。

   优点

   一个。需求1已解决。

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

   缺点

   一个。昂贵的解决方案。

如果我遗漏了什么或者是否有其他我们应该考虑的模式，您能否提出建议？

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

Answer 1

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

1. 应用程序将消息写入 SQS。

2. 一个 lambda 函数订阅了队列。

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

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