Lambda、SQS 和 Cloudwatch - 架构问题

Question

我有一个有趣的现实生活场景：

• 我有一个巨大的 SQS（消息非常多，不断地重新填充（最坏的情况，每秒 50 条消息）；
• 将使用 SQS 并将其推送到外部数据库的 Lambda（不幸的是，该数据库将以同步方式处理消息）。

约束：

• 最终的外部数据库不应连续处理数据，而是需要一些空闲时间。这是由于数据库活动成本（每 CPU 使用成本）；

• SQS 已经是架构的一部分；

• 最终的外部数据库不在我的控制范围内。

以下是我的解决方案、疑虑和问题：

• 解决方案 1：使用 Cloudwatch 每小时安排一次 Lambda，以便有时间消耗部分队列，然后让最终数据库空闲一段时间。

问题：队列可能“爆炸”，这意味着它可以很快填满并且处理速度很慢。

• 解决方案 2：创建一个由 Cloudwatch 触发的 Lambda (A) 每 X 次。此 Lambda 将循环 10 次并触发另一个 Lambda (B)，该 Lambda (B) 将消耗 10 条消息（SQS 中每个“时间？”的最大 msgs）并且也应该自动缩放。

问题：不确定自动缩放标准...看起来更梦幻。

• Sol 3（奖励）：创建第二个 SQS (2)。每 X 次将触发一个中间 Lambda (I)，并将消息从 SQS (1) 移动到 SQS (2)。 SQS (2) 上有一个事件将触发 Lambda (2)，这将自动扩展。

问题：过于混乱、过于复杂，与从 SQS (1) 移动到 SQS (2) 的消息数量有关。

现在

现在，很明显我的担忧与消费 SQS 和为数据库提供数据时的 Lambda 自动缩放有关。 此外，Lambda 应具有足够的扩展能力以消耗大量 SQS 消息，但同时应为最终数据库留出一些空闲时间。

我希望我已经很好地解释了这种情况，并且很乐意听取您的建议（很高兴学习！）。

谢谢， 毛罗

Answer 1

我会利用Lambda Reserved Concurrency。

1. 它限制了 lambda 的最大并发性，当队列爆炸时，它将作为一个节流阀。
2. 它保证 lambda 将始终具有运行能力。请注意，它也会减少您的帐户容量。假设您的帐户限制为 100，您为 lambda 保留的并发数为 10。您的新帐户限制为 90，但increase you account limit 很容易。

设置：

1. 首先将保留的并发设置为数据库可以轻松处理的内容。假设您将保留并发设置为 10，lambda 加载数据库需要 5 秒，并且您在 2 秒内获得 50 条消息的最大激增。您需要 50 秒才能清空队列。数学运算：(50 条消息 * 2) * 5 秒 / 10 lambdas = 50 秒。
2. 对于空闲时间，您可以将保留并发设置为 0，这将停止 Lambda 的运行。要自动执行此操作，您可以创建一个 CloudWatch 时间事件，该事件调用一个 Lambda，将预留并发设置为 0，然后另一个事件将预留并发设置回您的限制。