Lambda后续调用间的数据共享问题及替代方案咨询

核心结论 #

直接在多次Lambda调用之间共享那0.5MB的下载数据行不通——Lambda的每次调用都是独立执行的，即便有容器复用的情况，也没有任何机制能保证后续调用一定命中同一个实例，/tmp目录的共享完全是碰运气，根本不可靠。

可行方案 #

1. 合并逻辑到单次Lambda调用 #

既然输入是值数组，最省事的办法就是把所有逻辑放在一次Lambda调用里完成：

• 先下载那0.5MB的数据
• 遍历数组里的每个项，逐个完成比较操作
  这样完全不用拆分调用，自然也就避免了重复下载的问题，这是成本最低、最靠谱的方案。

2. 用共享存储缓存下载的数据 #

如果必须拆分多次调用，那就把下载好的数据存到Lambda能访问的共享存储里：

• S3：把下载的数据上传到S3的临时路径（可以给对象设置过期时间自动清理），后续调用直接从S3读取就行，0.5MB的数据读取速度快，成本几乎可以忽略
• ElastiCache（Redis/Memcached）：把数据存在内存缓存里，读写速度比S3更快，适合需要频繁读取的场景，0.5MB的大小完全没问题
  不管用哪种存储，记得设置好数据过期规则，别留一堆无用数据占空间。

3. Lambda层（仅适用于静态数据） #

如果这个0.5MB的数据是固定不变的（不是每次都要重新下载的动态数据），可以把它打包成Lambda层，每次调用Lambda时直接加载层里的数据，连下载都省了。但如果数据是动态的，这个方案就不适用了。

内容的提问来源于stack exchange，提问作者Amit Hajaj