ThinkPHP高并发优化方案-ThinkPHP-PHP中文网

thinkphp本身不解决高并发，真正起效的是php-fpm选static模式、关闭opcache校验、切换redis+swoole table缓存、订单号等关键路径原子化这四件事。

thinkphp高并发优化方案

ThinkPHP 本身不解决高并发，它只是被优化的对象；真正起效的是 PHP-FPM 模式选择、OPcache 配置、缓存驱动切换、关键路径原子化这四件事。

PHP-FPM 用 static 还是 dynamic？

高并发下 pm = static 更稳，尤其 ThinkPHP 内存占用较固定时。pm = dynamic 看似灵活，但 pm.max_children 实际可用值受 pm.start_servers、pm.min_spare_servers 等多参数隐式约束，压测时容易误判容量。

直接设 pm.max_children 为最大常驻进程数（如 64 或 128），避免 fork/spawn 抖动
单进程内存按压测值估算（含 OPcache、Redis 扩展等），留 20% 余量；例如占 40MB，8GB 内存服务器最多配 pm.max_children = 160
pm.process_idle_timeout 仅对 dynamic 有效，高并发下必须禁用，否则可能非预期回收进程

OPcache 必须关掉 validate_timestamps

opcache.validate_timestamps = 1 会让每次请求都 stat 文件修改时间——千万级并发下会打爆 ext4 的 inode cache 或引发大量磁盘 I/O 等待。即使设为 0，也需显式写出来。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

opcache.validate_timestamps = 0（生产环境必须关）
opcache.revalidate_freq = 0（配合上一条生效）
opcache.max_accelerated_files 至少设为 65536，ThinkPHP 5.1+ 类自动加载 + 模板编译易突破默认 2000 限制
启用 opcache.file_cache（如 /tmp/opcache），FPM 进程重启后可快速热加载

订单号生成别拼 microtime() + incr()

直接用 microtime(true) 拼 Redis INCR 值，在高并发下会撞——PHP 处理微秒级时间戳有精度损失，同一微秒内多个请求拿到相同时间部分；而 Redis 的 INCR 虽原子，若不同时间戳段共用一个 key，递增序号就错乱。

用 date('ymdHi')（分钟级）作 Redis key 后缀，如 order_sn_2405201530，确保同一窗口共享计数器
必须 SETEX order_sn_2405201530 86400 0 设置过期，防冷 key 持久占内存
incr() 调用要 while 重试 + 异常捕获：捕获 think\exception\DbException 和 Predis\Connection\ConnectionException
最终格式用 sprintf('%s%06d', $timestamp, $sn % 1000000) 固定长度，别硬拼字符串导致数据库索引效率下降

日志写入卡住接口？别改 Log::write()，重写 Log::save()

ThinkPHP 默认日志同步阻塞写文件，QPS 上千时磁盘 I/O 成瓶颈，常见现象是响应飙升、502、Too many open files 错误。根本原因是 Log::write() 底层调用 file_put_contents()，无缓冲、无异步、无队列。

不要在控制器里调用 Log::write() 记录业务日志；改用 Log::save() 并重写其实现，比如对接 syslog 或写入 Redis List 后由独立进程消费
禁用调试模式：app_debug = false，否则 trace 日志会严重拖慢响应
清空 runtime/log/ 目录并确认其权限可写，避免因文件锁或磁盘满导致写入阻塞

最常被忽略的其实是连接复用和缓存分层：deploy => 1 不是“读写分离开关”，而是连接复用的隐藏开关；而 Redis 缓存不是万能的，没设过期、key 设计混乱、大对象直存，都会让性能更差。