作为开发者，我们在处理大规模数据处理和交付时经常面临挑战。在 kamero，我们最近解决了文件传输管道中的一个重大瓶颈。我们的应用程序允许用户将与特定事件相关的数千个文件下载为单个 zip 文件。此功能由基于 node.js 的 lambda 函数提供支持，负责从 s3 存储桶中获取和压缩文件，但随着我们用户群的增长，该功能一直面临着内存限制和较长执行时间的问题。
这篇文章详细介绍了我们从资源匮乏的 node.js 实现到高效处理大量 s3 下载的精益且快速的 go 解决方案的历程。我们将探索如何优化我们的系统，以便在从特定事件请求大量文件时为用户提供无缝体验，所有文件都打包到一个方便的单个 zip 下载中。
挑战
我们最初的 lambda 函数在处理基于事件的大型文件集时面临几个关键问题：
- 内存消耗：即使分配了 10gb 内存，在处理较大事件的 20,000+ 个文件时，该功能也会失败。
- 执行时间：具有大量文件的事件的 zip 操作花费的时间太长，有时在完成之前就超时了。
- 可扩展性：该功能无法有效地处理不断增加的负载，限制了我们为用户提供流行事件中的大文件集的服务能力。
- 用户体验：缓慢的下载准备时间影响了用户满意度，尤其是对于文件数量较多的事件。
node.js 实现：快速浏览
我们最初的实现使用 s3-zip 库从 s3 对象创建 zip 文件。这是我们如何处理文件的简化片段：
const s3zip = require("s3-zip");
// ... other code ...
const body = s3zip.archive(
{ bucket: bucketname },
eventid,
files,
entrydata
);
await uploadzipfile(upload_bucket, zipfilekey, body);
虽然这种方法有效，但它会在创建 zip 之前将所有文件加载到内存中，从而导致大型文件集内存使用率较高，并可能出现内存不足错误。
输入 go：改变游戏规则的重写
我们决定用 go 重写 lambda 函数，利用其效率和内置并发功能。结果令人震惊：
- 内存使用量：对于相同的工作负载，从 10gb 降至仅 100mb。
- 速度：该功能速度提高了大约 10 倍。
- 可靠性：成功处理 20,000 多个文件，没有出现任何问题。
go实现中的关键优化
1. 高效的s3操作
我们使用了 aws sdk for go v2，与 v1 相比，它提供了更好的性能和更低的内存使用量：
cfg, err := config.loaddefaultconfig(context.todo()) s3client = s3.newfromconfig(cfg)
2. 并发处理
go 的 goroutine 允许我们同时处理多个文件：
var wg sync.waitgroup
sem := make(chan struct{}, 10) // limit concurrent operations
for _, photo := range photos {
wg.add(1)
go func(photo photo) {
defer wg.done()
sem <- struct{}{} // acquire semaphore
defer func() { <-sem }() // release semaphore
// process photo
}(photo)
}
wg.wait()
这种方法允许我们同时处理多个文件，同时控制并发级别以防止系统不堪重负。
3. 流式 zip 创建
我们不是将所有文件加载到内存中，而是将 zip 内容直接流式传输到 s3：
pipeReader, pipeWriter := io.Pipe()
go func() {
zipWriter := zip.NewWriter(pipeWriter)
// Add files to zip
zipWriter.Close()
pipeWriter.Close()
}()
// Upload streaming content to S3
uploader.Upload(ctx, &s3.PutObjectInput{
Bucket: &destBucket,
Key: &zipFileKey,
Body: pipeReader,
})
这种流式处理方法显着减少了内存使用量，并允许我们处理更大的文件集。
结果
对 go 的重写带来了令人印象深刻的改进：
- 内存使用量：减少 99%（从 10gb 减少到 100mb）
- 处理速度：提升约1000%
- 可靠性：成功处理 20,000 多个文件，没有出现任何问题
- 成本效率：更低的内存使用量和更快的执行时间可以降低 aws lambda 成本
经验教训
- 语言选择很重要：go 的效率和并发模型在我们的用例中产生了巨大的差异。
- 了解您的瓶颈：分析我们的 node.js 功能帮助我们确定需要改进的关键领域。
- 利用云原生解决方案：使用aws sdk for go v2并了解s3的功能可以实现更好的集成和性能。
- 以流的方式思考：将数据作为流处理而不是将所有内容加载到内存中对于大规模操作至关重要。
结论
用 go 重写 lambda 函数不仅解决了我们眼前的扩展问题，还为我们的文件处理需求提供了更强大、更高效的解决方案。虽然 node.js 最初为我们提供了良好的服务，但这次经历凸显了为工作选择正确工具的重要性，尤其是在处理大规模资源密集型任务时。
请记住，最好的语言或框架取决于您的具体用例。在我们的场景中，go 的性能特征与我们的需求完美契合，从而显着改善了用户体验并降低了运营成本。
您在无服务器功能方面是否遇到过类似的挑战？你是如何克服它们的？我们很乐意在下面的评论中听到您的经历！
