使用 Sqs 和 Lambda 处理与拆分批处理文件

Question

我想使用 S3-SQS-Lambda 架构处理不同的批处理文件并查看 3 种可能的设计方法

1. 选项 1 - 一次处理整个批处理文件

   • 文件传送到 S3
   • 第一个 Lambda 将在 SQS 中触发并创建消息
   • 第二个 lambda 将触发并立即处理批处理文件

2. 选项 2 - 处理批处理文件，分别处理每条消息

   • 文件传送到 S3
   • 第一个 Lambda 将触发并在 SQS 中为批处理文件中的每一行创建消息，每一行对应一条消息
   • 第二个 Lambda 将触发并一次处理一条消息

3. 选项 3 - 处理同时处理多条消息的批处理文件

   • 文件传送到 S3
   • 第一个 Lambda 将触发并在 SQS 中为批处理文件中的每一行创建消息，每一行对应一条消息
   • 第二个 Lambda 将触发并一次处理多条消息

我倾向于使用选项 3，因为从架构、可扩展性、处理/成本的角度来看，它似乎是中间选项，但希望专家提供有关他们如何比较这些选项的指示。

Answer 1

在您证明需要复杂性之前，更喜欢简单。

所有这三个选项在架构上看起来都是有效的。但针对不同的条件：

1. 这不需要您管理额外的基础架构。只要单个 lambda 始终可以在可接受的时间范围内完成批处理，我总是更喜欢这个选项。推理简单易行。
2. 如果您可以证明批处理中的每条消息都需要几秒钟的时间来处理并且您希望尽快完成批处理，请使用此选项。这是因为您将大规模并行执行工作，这将产生额外的复杂性和开销，因此如果只需要几毫秒来处理一条消息，那么您将不会意识到节省时间并且会更好选项...
3. 如果文件中的批处理大小太大而无法及时处理单个 lambda（例如选项一不合适），并且通过实验您发现有 理想的批量大小（例如，拆分和运行 lambda 的开销在消息数量较少时占主导地位，但在 100 条消息时，并行处理会变得更快）。

从选项 1 开始，它可以快速轻松地设置。如果处理时间太长，那么您已经证明需要复杂性，并且需要转到选项 2 或 3。我认为选项 2 是选项 3 的子集。所以写信给批处理逻辑和实验，看看什么样的批处理大小可以提供您需要的性能。