首页很快，但登录用户同时发出的客户区块、购物车和收藏请求一个接一个完成。PHP请求都在等同一个session锁，尤其某个接口持锁调用外部服务时，其他Ajax只能排队。

排查记录

我保留了一个失败样本，并用同样输入在无缓存或单节点条件下再跑一遍。这样可以把前端假象、缓存和真正的数据问题分开。

我先看了这几处

  • 用浏览器Waterfall看请求是并发发出却串行返回。
  • 在慢请求里对照Redis session日志与PHP-FPM active进程。
bin/magento config:show system/full_page_cache/caching_application
redis-cli --scan --pattern "sess_*" | head
grep -R "session.*locking|max_concurrency" app/etc/env.php vendor/magento/framework/Session -n
strace -p PHP_PID -f -tt 2>&1 | head

日志取样要带上请求时间、Store View、实体ID和部署版本。只截一行异常往往不够，至少保留错误前后几十行，才能判断是入口参数还是后续状态被改写。

处理办法

先缩短持锁请求：外部HTTP调用移到释放session之后或队列，纯读取接口避免不必要写session。按Magento Redis session配置合理设置max_concurrency、break_after_frontend和fail_after，不要直接全局关闭锁。对不需要客户状态的GET使用无session服务。

修改范围

  • 先在单个SKU、单个订单或单个Store验证。
  • 保留可回退的旧配置，不覆盖原始证据。
  • 需要批量处理时分批提交并输出成功/失败清单。

回归时别只刷新页面

  • 同一用户多Ajax并行完成
  • 购物车写请求仍保持一致性
  • 外部接口超时时不会拖住全部页面
  • Redis连接与PHP-FPM队列稳定

验收不只看后台提示“成功”。我还会从前台/API再走一次真实链路，并在下一轮cron、索引或缓存命中后重复检查，确认不是短暂正常。

补记

关闭Session Lock可能制造购物车丢商品、覆盖登录状态等竞态，必须用并发测试验证。

如果线上数据已经不一致，先停掉会继续扩大差异的入口，再修历史数据；否则一边补一边写，最后很难判断哪些记录已经处理。