PHP电商转化断点诊断：从点击到下单

　　去年五一期间，我在服务器后台盯单页转化漏斗，从商品列表页点击进详情页开始，到下单成功结束——就盯这一条链路，其他全关了。监控脚本跑着，我手边泡了三杯茶，茶叶都沉底了。

　　第七次刷后台时发现，详情页 PV 有 4127，但 add_to_cart 事件只有 638，再往下，submit_order 只有 291。我原以为是前端埋点漏了，结果翻 JS 日志，add_to_cart 的 trigger 都打了，连 timestamp 和 sku_id 都齐整；可 PHP 接口日志里压根没收到这 638 次请求——它没来，不是没回。

　　我让小王查 Nginx access log，他甩给我一段：全是 200，没 502，没 timeout，甚至没 499。但其中第八次重试时，他随手 grep 了下 upstream_addr，发现 72% 的请求打到了 10.3.12.17，剩下 28% 打到了 10.3.12.18——而后者是上周五刚切走的测试机，没开 PHP-FPM，只挂着 nginx 做静态转发。我问他为啥还挂负载池里，他说“备案系统显示它在线，所以自动加进去了”。

　　我删掉那台机器的权重后，下单数立刻跳到 287。二十来分钟，差 4 单。但第 288 单卡在 payment_init 接口上，response 是空的，curl -v 看 header 也全空，status 行后面直接断了。我抓包看到三次 TCP retransmit 后 RST，但 server 端 netstat 显示连接根本没建立——它连 accept() 都没进。反正，这事就发生在这儿。

文章配图，仅供参考

　　优胜劣汰这四个字，站得住的地方就在这儿：它不挑时间，不看节日，不等人喊开工。它就在那儿，一动不动，等你亲手把错误配置、未清理的旧节点、漏掉的 health check 全推到它面前。你推得越勤，它淘汰得越快；你推得慢，它就蹲着，啃你单量的边角料。我就盯着这个断点，盯着盯着，连晚饭都忘了点。

　　（对了，我桌角那盒蓝莓酸奶过期四天了，没扔；服务器机柜第二层左数第三个硬盘指示灯一直黄闪，但 SMART 检测说没问题——删掉这两句不影响这事讲清楚）

　　后来我扒 config.php 发现一个 include('config_local_bak.php')，文件存在，但里面 database_host 写的是 10.3.12.18——就是那台测试机。可奇怪的是，它只在下单前校验库存那段代码里被 require_once 了一次，其他地方全用的 config.php 正常变量。为什么偏偏这里加载了备份文件？我也不知道。我原以为是缓存污染，清了 OPcache 重试，照样断；我又以为是 auto_prepend_file 配错了，grep 了 php.ini，没这行；最后把它注释掉，重启 fpm，单量回到 292。但——为什么只这一个环节读了它？其他几十个接口都不认这个文件？我到现在没想通。

　　有谁碰到过这个吗？

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!