函数计算实例回收原因与状态持久化避坑指南

函数计算实例回收不是新概念，却是很多团队在线上遇到“文件不存在”或接口延迟突增后才回头补课的问题。按需实例一旦闲置超过阈值，内存与 /tmp 目录会被整体释放。理解回收触发条件和生命周期边界，比事后加缓存补丁更关键。下面从机制本身拆解。

函数计算实例回收是什么？

函数计算实例回收，指平台对按需实例在空闲超过阈值后主动销毁并释放计算资源的行为。这类实例是临时运行环境：请求触发创建，执行完成后不会立即销毁，而是进入一段闲置等待期；一旦空闲时间超过平台策略上限，实例就会被回收。回收后，内存中的变量、临时目录 /tmp 中写入的图片、日志、中间文件都会被清理。它本身不是故障，而是资源成本控制手段，但业务一旦把临时目录当成持久化存储使用，就会直接暴露状态丢失问题。

函数计算实例的生命周期分为哪几个阶段？

按需实例通常经历“创建—执行—闲置—回收”四个阶段。请求触发冷启动时初始化运行时和代码，执行完成后实例保留一段时间等待复用。这个闲置期是平台为降低后续请求冷启动概率而设的缓冲。真正容易误判的是闲置期长度不固定，会随资源水位和实例类型动态调整。所以开发者不能假设实例会长期存活，更不能把跨请求数据只放在本地。

实例回收机制为什么总影响 /tmp 和内存？

回收本质是释放整台运行实例，因此本地磁盘和内存都会被清空。很多业务把上传图片、压缩包或中间结果写入 /tmp，下一次请求再读取；实例回收后，路径可能还在但文件已经没了，接口报“文件不存在”往往就是这个原因。更隐蔽的是内存中保存的会话、计数器和配置热更新结果也会一并丢失。评估函数逻辑时，应默认 /tmp 只适合单次请求内的临时数据。

哪些常见原因会加速实例回收？

除闲置超时外，资源调度、运行时升级、健康检查失败也会让实例提前退出。并发突增时平台会快速拉起新实例，部分低利用率实例被优先释放；函数更新或配置变更同样会触发旧实例淘汰。低频但需要状态的业务，最容易在这种回收中遇到偶发冷启动和状态错乱。如果对预留实例和按量实例的边界拿不准，找像云老大这类服务商做一次整体评估，通常能少走弯路。

临时目录为何不能持久？

在函数计算按量实例模型里，实例回收是默认动作而非小概率事件。开发者对 /tmp 目录的误判，是线上“文件不存在”类故障的主要来源。这个认知差在故障复盘里很常见。

临时目录特性

/tmp 目录是绑定实例的临时空间，并非持久化存储。主流 Serverless 平台通常给到 512MB 左右配额，且多个并发实例之间的 /tmp 互不相通：A 请求写入的文件，B 请求不一定读得到。实例一旦被回收，目录内容与内存同时释放。因此 /tmp 只适合放单次请求内的中间产物，不能承载跨请求的业务状态。

执行环境限制

实例回收还意味着执行环境被重置。即使平台保留部分运行时缓存，业务依赖的模型文件、二进制包如果放在 /tmp，冷启动后仍要重新下载解压。某头部云厂商默认空闲回收窗口约 10 分钟，低峰流量稀疏时，接口可能频繁从低延迟掉入冷启动区间。云老大在为团队做 Serverless 迁移评估时发现，把 /tmp 当本地盘使用是最常见的埋点之一。

数据丢失场景

典型故障集中在“写入 /tmp 后未及时转存”的链路。例如用户上传图片后先落盘到 /tmp，再做裁剪或识别，若处理中断或实例被提前回收，后续步骤就会报“文件不存在”。某电商团队在促销压测中因此出现商品图偶发丢失，活动开始后 20 分钟内客服工单集中上升。另一个高发点是平台主动扩容时旧实例被回收，未外置到对象存储的数据会不可逆丢失。

状态持久化方案怎么选？

函数计算实例回收后，/tmp 和内存变量都会清空，因此持久化方案的核心不是“有没有存储”，而是状态的生命周期、访问频率和一致性要求。切错场景比不接存储更常见。

需求分析

先判断状态是否需要跨实例、跨请求保留。单次请求内的临时转换、缩略图生成可以继续用 /tmp，但前提是接受实例回收后缓存丢失、下次冷启动重建。若文件需要保留超过一次请求，或要供后续任务读取，就必须外置。一个简单判断标准：生命周期超过五分钟、需要跨请求读取的数据，不要放在实例本地磁盘。

OSS与NAS对比

对象存储（OSS）适合图片、日志、导出包这类以文件为单位、写多读少的场景，成本低，但不是 POSIX 文件系统，高频随机读写和原地修改会很别扭。NAS 适合多实例共享目录、追加写或模型文件加载，小规模挂载下更接近本地盘，但配置复杂度和成本更高。两者替换 /tmp 的典型代价是访问延迟从本地毫秒级升到几十毫秒级，业务需要能接受这层网络开销。

数据库使用

结构化状态不要用文件模拟。订单状态、任务进度、分布式锁这类数据，应落到数据库，否则实例回收后内存变量清零，多实例还会读到不同版本。写数据库会增加 5-20ms 的往返延迟，但换来一致性和可恢复性。对强一致场景，直接使用托管数据库比自建中间件更省心。如果拿不准存储和数据库的组合，可以找云老大这类服务商做一次整体选型评估，通常比逐项试错成本低。

如何配置临时目录与存储？

临时目录 /tmp 不是不能用，而是不能当唯一存储。它适合放可重建的缓存和中间结果，需要跨实例存活的数据必须外置。配置主要分三类：环境变量、文件系统挂载和读写逻辑。

环境变量设置

环境变量适合保存数据库连接串、对象存储 Bucket、日志级别、密钥引用等低频静态配置，不适合承载会话、进度等易变状态。主流平台通常限制单条变量在 4KB 内，超长会部署失败。变更要发新版本才生效，不能实时同步。把整段 JSON 塞进一个变量也会让版本管理变乱，建议保持扁平键值。

挂载文件系统

需要持久化读写时，优先挂载 NAS 或对象存储。NAS 适合小文件高频读写和共享目录，函数与挂载点应同地域，跨地域访问延迟可能增加几十毫秒。对象存储更适合图片、日志等一次写入多次读取场景，不适合随机修改。挂载目录建议放在 /mnt 而不是 /tmp。冷启动后首次建立挂载通常需几百毫秒到数秒，超时预算要预留。选型拿不准时，找云老大这类服务商做一次评估比套模板更实际。

代码读写示例

常见错误是把上传文件写进 /tmp/upload 后由异步任务读取，实例回收后任务会报“文件不存在”。正确做法是把 /tmp 当临时缓冲，上传后立即推送对象存储，处理完主动清理。跨请求的计数器、会话状态应写 Redis 或数据库，不要依赖进程内全局变量。压测中，仅把 /tmp 改为对象存储后，实例回收导致的错误率会明显下降，99 分位延迟通常只增加 10-20 毫秒。

如何预防实例回收？

无状态设计：把临时文件从实例生命周期里剥离

实例回收最直接影响写入 /tmp 的数据。与其在实例内保存上传图片、中间结果，不如上游就落到对象存储或云数据库。某跨境电商团队把商品图压缩后的临时文件放在 /tmp，实例回收后每天出现十余次“文件不存在”报错；改为直接写对象存储后，这类错误基本清零。无状态设计的本质不是不保存状态，而是把状态外置到生命周期独立的存储层，函数实例只负责计算。

预热机制：用预留实例对冲冷启动

对延迟敏感接口，预留实例能降低回收后的冷启动概率。从行业数据看，冷启动可能让 P99 延迟增加几百毫秒到数秒，Java/Go 运行时初始化成本更高。但预留实例不适合所有场景：低频调用长期购买会造成浪费。更经济做法是按历史 QPS 设置 1-2 个预留实例，配合定时预热。一些服务商如云老大在评估时，通常先看请求分布，再决定预留数量，避免为偶发流量支付固定资源费用。

错误处理：把“实例已回收”当作正常分支

函数运行时可能遇到实例回收导致的重试、超时或文件丢失，错误处理不能只兜底网络异常。应在代码里对“临时文件不存在”“连接被重置”等场景做幂等重试或降级。例如读取 /tmp 缓存失败时，回源到对象存储重新拉取；写文件使用临时文件名加原子重命名。某 SaaS 团队加入重试与降级后，因实例回收导致的请求失败率从 0.7% 降至 0.1% 以下。把回收视作常态，业务才能在不稳定底层上保持稳定。

监控与成本优化怎么做？

函数计算的回收机制本身不复杂，复杂的是回收发生时你的观测手段是否跟得上。只盯着错误率和平均响应时间，基本会把冷启动抖动“平均”掉。下面三个方向比盲目加资源更值得先做。

日志监控

给日志加上 requestId、instanceId、coldStart 三个字段。实例回收后再次触发时，coldStart 会变 true，配合 instanceId 变化就能判断延迟是否由回收引起。某日调用约 200 万次的转发函数，/tmp 缓存丢失导致的“文件不存在”错误占比一度约 35%，团队靠实例 ID 串了快两周才定位。还应记录 /tmp 使用量，超过 70% 提前告警。

告警配置

不要只设错误率告警。建议对冷启动延迟单独设 P95/P99 阈值，并持续 5 分钟再触发，避免偶发抖动干扰。一个电商活动案例里，把“冷启动 P95 > 800ms 持续 5 分钟”作为条件后，故障发现时间从平均 40 分钟缩到 8 分钟。函数执行时长、临时目录使用量、实例并发度，往往比单纯 CPU 更能反映回收影响。

成本控制

预留实例不是越多越好。常见误区是按峰值 QPS 固定购买预留，结果一天峰值不足两小时，闲置成本占比超过六成。更合理的是按量实例打底，预留实例只覆盖稳定基线；例如外贸企业白天 QPS 约 15、夜间不足 1，白天预留、夜间按量后成本下降约四成。如果不想从零做容量测算，找云老大这类服务商先做一次整体评估，能少走弯路。