Spring Boot高并发场景下EFS访问致性能下降如何优化

你之前把预置吞吐切到突发模式没有效果是非常典型的认知误区：突发模式的吞吐额度和EFS存储的文件总容量强绑定，每TB存储仅提供50MB/s的基准吞吐，突发信用是随时间累积的，如果你存储规模不大，高并发流量打上来几分钟就会把突发信用耗光，直接跌回极低的基准吞吐，自然看不到性能改善。
以下是经过生产验证的可落地优化方案：

EFS 服务端配置调优 #

• 吞吐模式按需选择：先统计业务峰值的持续吞吐、IOPS需求，如果峰值持续时间超过15分钟，直接切回预置吞吐模式，按峰值需求的1.2倍配置额度，不要卡着平均值买；如果是短时间（几分钟以内）的突发流量，再考虑用突发模式，同时提前确认存储规模对应的基准吞吐能扛住信用耗光后的兜底流量。
• 性能模式不要选错：如果你的业务有大量小文件读写、文件列表查询、属性校验这类元数据操作，高并发场景下直接切换到Max I/O性能模式，相比默认的通用模式，Max I/O的元数据并发处理能力有数倍提升，高并发下的延迟毛刺会少很多。
• 挂载参数优化：应用实例挂载EFS时不要用默认参数，添加如下挂载参数降低额外开销：tls,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noatime，将读写块大小调整为1MB，关闭文件访问时间自动更新的元数据写操作，实测高并发下能降低20%~30%的访问延迟。
• 存储分层规则校验：检查生命周期策略，确保高频访问的文件没有被自动转到低频存储层，低频存储层的访问延迟是标准层的3倍以上，还会额外收取请求费用，高并发场景下会直接拖慢接口响应。

Spring Boot 应用侧访问逻辑优化 #

• 砍掉冗余的元数据操作：很多业务代码读文件前会重复调用exists()、isFile()、length()这类元数据检查接口，高并发下这类操作对EFS元数据服务的压力远大于实际文件内容读取，非必要场景下可以直接执行文件读写，通过捕获异常处理文件不存在、权限不足等场景，减少无效元数据请求。
• 文件句柄池化：不要每次请求都新建、销毁文件流，高并发下频繁创建NFS文件句柄的开销非常高，可以用Spring内置的文件系统抽象或者Apache Commons VFS做句柄缓存，控制单实例并发句柄数不超过1000，避免触发EFS单挂载点的句柄数限制。
• 高频访问文件本地缓存：对于不常变更的配置文件、处理模板、静态资源，应用启动时直接加载到实例内存或者本地临时盘；对于动态生成的热点文件，处理完成后在本地缓存1~5分钟，重复请求直接走本地返回，不需要重复访问EFS。
• 降低文件锁粒度：EFS基于NFS协议实现，跨实例的全局文件锁开销极高，如果存在多实例同时写同一个文件的逻辑，高并发下锁等待会把响应耗时拉到秒级。建议改造为按业务唯一键分片写，不同实例写不同的文件分片，最后异步合并，尽量避免跨实例的全局文件锁。
• 临时文件下沉到本地盘：Spring Boot文件处理过程中生成的临时分片、中转文件，全部写到实例本地临时目录，不要放到EFS挂载路径下，这类无状态的临时IO通常会占EFS总请求量的30%以上，完全没必要占用EFS吞吐。

架构层面分流优化 #

• 热点请求前置缓存：如果业务是读多写少场景，在应用和EFS之间加一层缓存，小文件热点内容直接存Redis，大文件用Nginx做边缘缓存，热点请求根本不打到EFS，性能可以提升一个数量级。
• 业务目录拆分挂载：不要把所有业务文件都堆在同一个EFS根目录，把小文件元数据密集型业务、大文件顺序读写业务、归档文件业务拆到不同的EFS目录，甚至单独搭建EFS文件系统，避免不同业务之间的IO争抢。

快速排查定位技巧 #

• 高并发压测时在应用实例上执行nfsstat -m查看EFS挂载点的重传率、平均响应延迟，如果重传率超过5%，说明当前EFS的吞吐/IOPS已经打满，需要升配或者做流量分流。
• 看监控指标不要只看控制台的平均值，要拉取1秒粒度的读、写、元数据操作P99延迟，定位到底是哪类操作导致的延迟毛刺，不要盲目调配置。

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