在 SQS lambda 环境中扇出的推荐方法是什么？

Question

我想通过 SQS / 消息队列架构在 lambda 环境中向我的数据库中的用户发送推送通知，以便做到这一点

1. 我首先需要查询数据库中启用推送通知的所有用户。
2. 遍历所有这些
3. 为每个用户发送 SQS 事件/消息。
4. 让我的 sqs 触发的 lambda 处理/发送推送通知

有没有更好的方法来实现这一点，以避免查询大量用户和/或循环遍历所有结果来为每个用户发送 SQS 消息？

Answer 1

我会在这里采取稍微不同的方法，但类似。

1. 为用户查询数据库
2. 遍历用户
3. 向SQS发送一条消息，用于发送一批记录，使用SQS的SendMessageBatch操作发送。所以一批批。每批消息都会有几个“用户”要发送给，而不仅仅是一个。这应该会提高您的性能，因为批处理将需要更少的 lambda 调用。
4. Lambda 处理 SQS 消息（可能不止一条），每条 SQS 消息都会导致发送许多推送通知。在 Firebase 的情况下，我相信有一种方法可以发送批次，这会更好。即使没有，您也可以使用 Promise.all 类型逻辑一次发送多条消息。

使用这种结构，您可以非常快速地发送大量消息，而且可能会便宜很多。想象一下，您需要发送给 100 万用户。如果您批量发送 100 条，每批 25 条发送到 SQS，那么每次调用 SQS 有 2,500 条消息。这意味着对 SQS 的 400 次调用，甚至比如果您分批发送 25 条消息所必须进行的 40K 次要好得多。

在接收端，即使您将 SQS 集成限制为每次调用 1 条消息，您也会有 10,000 次 lambda 调用。如果您假设每次调用甚至 1 秒，以及 1000 次并发调用，则需要 10 秒（可能更少）。如果您为每个用户发送一条消息，则必须进行 1M 次 lambda 调用。如果您假设每次调用需要 100 毫秒，那么您可以发送 10/秒，因此如果有 1000 次并发执行，则需要 100 秒。实际上，这些数字可能比批处理版本的数字还要好，尤其是如果您不将其限制为一次 1 条消息。

编辑 根据 cmets，问题似乎更多的是关于过程的第一部分。考虑到这一点，我建议以下选项。

1. 如果您发现自己需要重复处理相同的大型群组，大多数消息服务（当然是 Firebase 和 SNS）都支持某种主题订阅模型。鉴于这些是推送通知，您可以在代码中为设备订阅主题。这最终会导致一条消息从您的代码发送到消息传递服务。该服务处理其余部分。这可能是任何有大量收件人的首选解决方案，特别是如果您可以预先知道收件人。这甚至适用于动态主题。例如，考虑一个人在帖子上遇到的情况。对该帖子的任何新评论都应向所有对该帖子发表评论的人发送消息。您可以在创建帖子时即时创建主题，并在他们发表评论时将收件人添加到主题中。如果用户希望停止接收消息，您可以从主题中删除该用户。
2. 如果您事先不知道收件人，上述解决方案是一个可靠的解决方案。但是，如果您担心前两个步骤中的 Lambda 超时，我会稍作修改。我会利用 AWS Step Functions 并在 lambda 中分页数据。 Lambda 将通过调用中提供的context 对象告诉您还剩多少时间。您可以定期检查以确定是否应该退出 lambda 并将当前分页信息传递给 step 函数。 step 函数可以将该分页信息传递回 lambda，它应该被编码为接受分页信息作为请求的一部分，并从该点继续（如果提供）。

Answer 2

我建议在您的应用程序架构中增加一个部分，
我个人更喜欢避免使用主数据库进行繁重的查询，
假设您拥有庞大的用户群。

我建议在 ElasticSearch 或 CloudSearch 等搜索引擎中维护您的用户列表，或者在 AWS DynamoDb 中仅包含用户列表的简单表，或者创建数据库的只读副本。
为了不让您感到困惑，请使用搜索引擎（首选）或 AWS DynamoDb

这将避免在查询读取专用数据存储时对数据库造成压力，并且不会影响其他运行中的模块
而且这种方式查询速度很快

第 2 步：遍历所有这些

第 3 步：使用 Jason 建议的 SendMessageBatch 方法向 SQS 批量发送消息

第 4 步：根据您的 SQS 设置，您可以在 Lambda 函数上处理多条消息