使用 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，因为从体系结构、可扩展性、processing/cost 的角度来看，它似乎是中间选项，但希望专家就如何比较这些选项提供指导。

Answer 1

在证明您需要复杂性之前，请选择简单性。

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

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

从选项 1 开始，该选项设置起来既快捷又容易。如果处理时间太长，那么您已经证明需要复杂性，并且需要移动到选项 2 或 3。我认为选项 2 是选项 3 的 sub-set。所以写入批处理逻辑并进行实验，以查看多大的批处理大小可提供您需要的性能。