我们正在为我们的应用程序尝试多区域体系结构。由多个客户端使用。
我们正在使用aws复制数据库（s3和dynamodb），它解决了数据可用性问题。
只要有任何数据更改，我们都使用SNS通知客户，但我找不到跨邮件复制的任何好模式。
以下是我们需要牢记的一些考虑事项/要求
即使客户端仅在一个区域中，他们也应该能够获得所有通知。
即使一个区域出现故障，应用程序也应继续工作。并且，如果可能的话，可以在区域出现时重播消息。
这里浮现出几种利弊的方法。
EC2服务器写入两个区域
优点。
a。要求1很容易满足。
缺点。
a。不确定是否可行，因为没有文档建议这样做。
b。如果一个区域出现故障，将无法重播消息。
c。延迟会延迟写入两个区域。
具有lambda函数以写入两个区域。由于lambda函数可以订阅跨区域的sqs和sns。我们可以在两个区域中都具有lambda函数，以侦听另一个区域的sns / sqs，然后写入其自身区域的sns。
优点：
a。要求1已解决。
b。 如果使用sqs而不是sns，则要求2得以解决，如果该区域关闭，则消息将在队列中保留一段时间，并且每当区域出现时将重播消息。跨区域sqs订阅不是可能，lambda函数必须订阅sns。
缺点：
a。跨区域权限意味着在cloudformation中进行硬编码，不确定cloudformation是否支持从其他区域导入。
b。 Lambda函数的成本。 （尽管会很小）
我们没有编写sns，而是编写了dynamodb，并使用dynamodb全局表和流在这两个区域中发送通知。
优点。
a。要求1已解决。
b。 dynamodb复制将负责复制消息，因此解决了要求2。
缺点。
a。昂贵的解决方案。
您能建议我是否缺少任何东西，或者有其他应该考虑的模式吗？
着眼于以上可能的方法，我倾向于方法2，
答案 0 :(得分：1)
我们最终使用这种方法解决了问题
向SQS的应用程序写入消息。
lambda函数已预订到队列。
Lambda函数同时写入该区域的sns。
通过这种方式，我们可以在发送消息之前引入延迟和一些预处理。但是，IMO最好的解决方案是使用dynamodb流生成消息（不是新的dynamodb表，而是来自我们正在写入数据的表），因为这意味着在特定区域中发送消息时，数据已经被复制。