PHP Session 高并发为什么会卡住：从文件锁迁到 Redis 会话存储

PHP 项目里同一个用户连续点几次页面，后面的请求莫名其妙排队，很多时候不是 MySQL 慢，也不是 PHP-FPM 进程不够，而是默认文件会话锁把请求串起来了。只要请求里调用了 session_start()，又迟迟没有释放会话，后续同一个会话 ID 的请求就可能等锁。高并发下想把这类问题处理干净，通常要先缩短锁持有时间，再考虑把会话存储迁到 Redis。

请求变慢时先看是不是会话锁

会话锁的典型现象辨识度很高：同一个用户连续发起多个请求，后面的请求要等前一个完全结束才能执行；换个浏览器、换个账号访问同一批接口，大概率就不会卡顿。尤其是报表导出、大文件上传、后台长轮询这类耗时长的接口，只要它们启动后一直持有会话，同账号的其他轻量接口也会被拖住。

排查时可以先翻 PHP-FPM 慢日志、接口耗时统计和访问记录。如果慢接口的执行流里很早就调用了 session_start()，后续又触发了大量库表查询、第三方接口调用或是大文件处理，那会话锁就是高概率的根因。

默认文件会话为什么容易放大瓶颈

PHP 默认的文件会话实现简单稳定，完全能覆盖小规模、单机部署、请求耗时短的场景。它的核心问题是同一个会话对应的存储文件会被排他锁定，当前请求没释放锁之前，后续同会话 ID 的所有请求只能原地等待。普通用户感知不到底层的锁逻辑，只会看到页面加载转圈、按钮点了没反应、操作迟迟不出结果。

很常见的错误写法是：进入控制器就启动会话，读取完用户ID、权限状态之后，还一直持着锁跑完整个完整的业务流程。

如果 buildLargeReport() 的执行要跑十几秒，同一个用户在这段时间里打开其他普通接口，就会被会话锁卡住。这一步不用急着直接上 Redis 重构，优先把会话锁尽早释放，成本更低见效更快。

先用 session_write_close 缩短锁持有时间

如果当前接口只需要读取会话里的用户ID、角色或是登录状态，读完之后马上调用 session_write_close() 就可以。这个操作会把当前内存里的会话数据持久化到存储，同时主动释放掉会话锁，后续执行的慢查询、报表生成、第三方接口调用逻辑，就不会再阻塞同账号用户的其他请求。

这个优化步骤的改造成本很低，也适合先在小范围流量灰度验证。需要注意的是，调用 session_write_close() 之后再修改 $_SESSION 变量，不会自动把改动同步持久化到存储。涉及登录态续期、购物车更新、验证码计数这类确实需要写入会话的接口，要把所有写入操作放在主动关闭会话之前完成。

迁到 Redis 后会话架构怎么变

当应用从单机部署扩容到多台 PHP-FPM 节点，或是本地文件会话已经没法满足多节点共享、统一管控的需求，就可以考虑把会话存储迁移到 Redis。Redis 带来的收益不只是读写速度更快，还能实现多节点共享会话、统一管控会话有效期、更方便地观测所有会话键的运行状态。

核心配置可以直接写到 PHP 的配置文件里，也可以在对应框架的启动初始化阶段动态设置。不同环境里安装的扩展、不同框架的封装写法会有差异，下面只展示核心逻辑：

生产环境部署不要只写默认的本机地址。要按照实际部署架构配置 Redis 的连接地址、密码、连接超时时间、库编号和键名前缀。多个业务项目共用同一个 Redis 实例的时候，自定义前缀非常重要，不然不同项目的会话键混在一起，后续排查问题的难度会高很多。

关键取舍不是 Redis 越快越好

迁移到 Redis 之后，整个链路的瓶颈位置也会跟着变化。之前要担心本地文件锁的排队问题，现在要重点关注 Redis 的可用性、跨节点网络延迟、键过期策略和连接池的负载压力。会话本身的存储体量不适合太大，用户头像、全量权限树、临时业务表格这类内容，更适合放到独立的业务缓存或是数据库里。

上线后要看哪些信号

迁移完成后的验证不能只看“没报错”，更可靠的观测维度包括：同一个用户连续发起的多个请求耗时有没有明显下降，PHP-FPM 慢日志里会话相关的等待记录有没有减少，Redis 的慢查询和延迟指标能不能维持稳定，用户侧的登录态丢失反馈有没有增加。

可以把这些观测点整理成核对清单逐一确认：

• 接口 P95/P99 耗时有没有下降，尤其是报表、导出、上传操作之后紧跟的普通接口。
• PHP-FPM 慢日志里还会不会频繁出现会话启动后长时间阻塞的记录。
• Redis 的内存占用、连接数、延迟和过期键数量是不是在预期范围内。
• 有没有用户反馈频繁掉线、验证码无故失效、购物车状态异常丢失的问题。

常见问题

PHP Session 迁到 Redis 后还会有锁吗？

实际表现取决于所用的扩展和配置。迁移到 Redis 能解决多机共享和本地文件存储的瓶颈，但如果接口逻辑里长时间持着会话不释放，同样会出现排队问题，读完会话尽早关闭的优化逻辑，迁移之后依然适用。

所有接口都要调用 session_write_close 吗？

不用统一强制修改。只有只读会话的慢接口优先改造收益最高；需要写入登录状态、验证码、购物车数据的接口，要保证所有写入操作执行完成之后再关闭会话。

会话里能不能放很多业务数据？

不建议。会话本身的定位就是存少量登录态和用户上下文，大块的业务数据应该存到业务表、独立缓存或是对象存储里。会话存储的体量越大，读写操作的网络传输和序列化开销就越高。

Redis 会话 TTL 应该设置多久？

一般设置成和产品定义的登录有效期一致就可以，同时结合业务侧的自动续期逻辑调整。有效期设得太短会让用户频繁掉线，设得太长又会增加无效会话残留的风险，也会提升安全层面的隐患。

小结

PHP 会话卡顿的核心逻辑从来不是“文件存储就一定差，Redis 就一定最优”，而是会话锁的持有策略和存储选型，要匹配当前业务的实际规模。单机短请求的场景可以先优化会话锁的释放时机；多节点部署、高并发访问的场景，再把会话迁移到 Redis 存储，同时提前配置好合理的 TTL、键前缀、连接超时和故障回退逻辑。这样改造完成之后，性能提升会更稳定，后续线上出现相关问题也更容易定位排查。