docker tmpfs挂载专为微服务中高频、低延迟、强隔离的临时数据场景设计，数据仅驻内存、不落盘、容器停止即清空，io吞吐提升80%～90%；典型应用包括用/tmpfs替代磁盘缓存目录（如/app/cache:size=128m）、搭配内存数据库实现分布式会话存储（如/run/session:mode=700,size=32m），以及保护敏感凭证（如/app/secrets:size=8m, noexec,nosuid）；需强制设置size防oom，且仅限linux主机生效。
在微服务架构中，缓存加速与会话存储是高频、低延迟、强隔离需求的典型场景。docker tmpfs 挂载正是为此类临时数据量大、生命周期短、安全性要求高的环节而设计的——它把数据直接放在内存里，不落盘、不跨容器、不残留，性能提升明显，实测 io 吞吐可提高 80%～90%。
微服务缓存加速：用 tmpfs 替代磁盘缓存目录
比如一个 Spring Boot 微服务使用 Caffeine 或 Ehcache 做本地缓存，同时依赖文件系统暂存序列化快照或预热数据，若挂载到磁盘卷（volume），频繁写入会导致 I/O 瓶颈。改用 tmpfs 可彻底规避该问题：
- 将
/app/cache目录挂载为 tmpfs，设置size=128m防止无节制增长 - 添加
noexec,nosuid选项，禁止执行和权限提升，防止缓存污染引发提权 - 应用启动时自动初始化该路径，无需额外清理逻辑——容器停止即清空
- 对比测试显示：相同并发下，响应 P95 延迟从 42ms 降至 9ms
分布式会话存储：tmpfs + 内存数据库组合方案
当微服务集群不依赖外部 Redis 存储 session（例如灰度环境或单机调试），可用 tmpfs 搭配轻量级内存数据库实现“伪共享”会话：
- 启动容器时挂载
--tmpfs /run/session:rw,mode=700,size=32m，专供 session 文件读写 - 应用内配置 Session Manager 将 session store 指向该路径（如 Tomcat 的
FileStore） - 配合
mode=700保证仅属主可访问，避免多租户会话泄露 - 容器重启后 session 自动失效，符合“无状态服务”设计原则，也省去手动清理 session 文件的运维脚本
敏感会话凭证的临时落盘保护
某些微服务需在运行时生成短期 JWT 密钥、OAuth2 token 加密材料等，传统做法写入 /tmp 易被主机扫描或误备份。tmpfs 是更稳妥的选择：
- 挂载
--tmpfs /app/secrets:rw,noexec,nosuid,mode=700,size=8m - 应用启动时生成密钥对并存入该路径，仅限当前进程读取
- 容器异常退出或被 kill 后，密钥立即从内存抹除，物理上不可恢复
- 相比 bind mount 到主机
/tmp，杜绝了宿主机侧残留风险
注意事项与避坑点
tmpfs 不是万能加速器，实际落地要注意三点：
- 必须显式设 size：不设 size 时，tmpfs 可能吃光容器内存，触发 OOM Killer；建议按峰值缓存大小 × 1.5 设置上限
- 不能跨容器共享：tmpfs 绑定到单个容器生命周期，会话/缓存无法被 sidecar 或其他服务直接读取，需搭配 Redis 或 gRPC 共享机制
- Linux 主机专属：macOS 和 Windows 上 Docker Desktop 使用虚拟机模拟，tmpfs 实际仍走 VM 内存，性能增益有限，生产环境务必部署在 Linux 节点
