简介php-redis 的 pconnect 连接机制一直是 PHP 开发者讨论的热点很多人误以为它无法跨请求保持连接。这份 PDF 针对这一疑惑给出明确答案通过解读官方文档与 PHP-FPM 运行机制pconnect 创建的连接确实会在请求结束后继续保留并一直持有到子进程处理完 max_requests 次请求后重启才会释放。文档随后用 tideways 扩展做了两组对照实验第一次连续请求时日志显示 pconnect 只出现一次第二次请求则没有待手动重启 php-fpm 后第一次请求又出现了 pconnect 调用。这些截图与日志直观验证了连接的生命周期边界并进一步解释了这种特性对 Redis 连接数、高并发下资源占用以及 max_requests 合理配置的现实影响。内容包含测试代码、命令行操作记录和性能分析结果是一条完整的排查与验证思路。资源为单个 PDF 文件大小仅 47KB干货浓度高。目前已有 732 人学习适合中高级 PHP 开发者、Redis 运维人员以及正在优化 FPM 配置的架构师阅读。1. pconnect 长链接一个连接数幻觉引发的血泪排查某天接口 QPS 突然掉了一半Redis 侧 maxclients 被打满redis-cli info clients显示 connected_clients 几千个。当时第一反应是换用pconnect长链接复用连接结果改完一上线连接数不但没降反而在 FPM 空闲时依然稳定挂在 Redis 上——这就是 php-redis 的 pconnect 最典型的误解现场。连接没有消失只是不再随请求结束而关闭了。这篇文章会把 pconnect 在 PHP-FPM 和常驻进程两条路线下的真实行为拆开讲清楚包括为什么它不适合当“性能银弹”、什么场景才值得接入、连接复用后哪些状态会串味以及最后怎么用两个命令验证它到底有没有生效。适合被连接数问题困扰的 PHP 后端开发者也适合准备在 Swoole 项目里做 Redis 连接池的读者。2. pconnect 和 connect 的本质差异长连接到底“长”在哪个环节2.1 一次 connect 请求Redis 侧和 PHP 侧各自发生了什么先用最常见的connect走一遍。每次请求执行$redis-connect(127.0.0.1, 6379)PHP 会发起一次 TCP 三次握手Redis 侧为这个连接分配一个连接对象PHP 脚本执行完毕后Redis对象被销毁析构流程里会发送QUIT并关闭 socket。也就是说?php // 普通 connect请求生命周期内有效 $redis new Redis(); $redis-connect(127.0.0.1, 6379, 0.5); $redis-set(foo, bar); // 脚本结束 → 析构 → 发送 QUIT → 四次挥手这段代码的逻辑很清楚connect建立连接set执行命令脚本结束后扩展层自动释放连接句柄。这里0.5是连接超时单位秒表示 TCP 握手阶段最多等待 500ms。注意这个参数只影响建连过程不影响读写阶段。再换成pconnect?php // pconnect连接不随请求结束关闭存入扩展层的持久连接池 $redis new Redis(); $redis-pconnect(127.0.0.1, 6379, 0.5); $redis-set(foo, bar); // 脚本结束 → 连接不关闭句柄保留在 PHP 进程内存中关键区别在最后一行请求结束后连接被放回扩展内部的一个哈希表键是host:port。同一个 PHP 进程FPM worker下一次再执行pconnect(127.0.0.1, 6379)会直接从哈希表里取出旧连接不再走三次握手。这就是 pconnect 的“长”字本质——它不是 Redis 服务端做了什么特殊处理而是 PHP 扩展层和 FPM 进程模型配合出的连接复用机制。2.2 PHP-FPM 进程模型下pconnect 的“长”是建立在谁的生命周期上要理解 pconnect 的边界条件必须先把 PHP-FPM 的进程模型摆出来。FPM 启动后会 fork 出固定数量的 worker 进程每个 worker 独立处理请求。关键事实是worker 是常驻的但 PHP 脚本本身是“用完即弃”的——每次请求结束所有用户态变量、类静态属性、全局对象都会被清空。pconnect 能跨越请求存活是因为连接句柄存到了扩展层C 语言实现的静态变量里不受 PHP 用户态变量销毁影响。它挂在 worker 进程的内存空间中只要 worker 不退出连接就一直在。于是就有了这个结论connect的连接生命周期 ≈ 一次 PHP 请求pconnect的连接生命周期 ≈ 一个 FPM worker 进程的生命周期所以 pconnect 的“长”本质上是蹭了 FPM worker 的常驻生命周期。如果用的是 PHP-FPM连接数上限理论上等于worker 进程数 × 每个进程维护的连接数。如果用的是 CLI 跑一次性脚本pconnect 完全没意义——脚本结束进程退出连接跟着关闭。2.3 为什么长连接在 PHP 里的收益常被高估一次请求内的微耗时拆解很多团队换 pconnect 的理由是“减少 TCP 握手提升性能”。这个理由不能说错但要先看一眼 Redis 请求的耗时构成。以本机回环地址为例我做过的粗略测量是一次 TCP 三次握手大约 0.02ms 到 0.1ms而一次 Redis 命令的往返在 0.1ms 到 0.5ms 量级。也就是说即使每次请求都重新 connect单次连接建立只占几十微秒。压测不要看单个请求要看整体。在一台普通服务器上用ab压一个只做$redis-set()的接口connect 版和 pconnect 版的 QPS 差距通常在 5% 到 15% 之间。这个差距在业务本身有数据库查询、外部 HTTP 调用时会被稀释到几乎不可感知。那 pconnect 存在的意义到底是什么真正有价值的地方是控制连接数而不是提升速度。在高并发场景下如果每次请求都新建连接而单个请求处理时间较长Redis 侧连接会在请求处理期间持续累积。换成 pconnect 后连接数被锁定在 worker 进程数量级别不会随请求并发波动。这才是接入 pconnect 的第一理由而不是“快”。3. 接入 pconnect 的正确姿势单例封装、参数调整与最小实现3.1 先用一张表判断你的场景到底该不该用不是所有项目都适合 pconnect。我把常见情况整理成一张选型表方便直接对照场景特征建议理由FPM 静态/动态 worker请求量波动大连接数经常冲高推荐 pconnect连接数收敛到进程数避免 Redis 连接数被打满单机低频业务每天请求量几千用 connect 即可pconnect 带来的连接复用收益极小反而增加排查成本CLI 脚本、定时任务用 connect进程结束连接就关闭pconnect 形同虚设Swoole/Workerman 常驻服务推荐 pconnect 连接池worker 内复用真正有意义但要注意协程隔离Redis 服务端频繁重启、网络不稳定慎用 pconnect长连接在断线后可能残留脏状态必须有重连机制如果你只是觉得“别人都用长链接所以我也要用”大概率会掉进第 4 章说的坑里。pconnect 不是性能优化是连接数治理手段。3.2 PRedis 单例封装带认证、库选择与重连的最小实现接入 pconnect 最常见做法不是每次new Redis()直接 pconnect而是封装一个单例类统一管理连接、认证、选库和断线重连。下面这个是我常用的写法?php class PRedis { /** * 配置缓存不同实例不同配置 * 注意static 不会跨请求保留真正复用连接的是扩展内部池 */ private static array $configs []; private string $name; private ?Redis $conn null; private function __construct(string $name) { $this-name $name; self::$configs[$name] [ host 127.0.0.1, port 6379, timeout 0.5, // 连接超时秒 auth , // 密码没有则为空串 db 0, // 默认库 ]; } public static function instance(string $name default): self { static $instances []; if (!isset($instances[$name])) { $instances[$name] new self($name); } return $instances[$name]; } public function conn(): Redis { if ($this-conn) { // 轻量探测ping 失败说明链路断了需要重新建立 try { if ($this-conn-ping() PONG || $this-conn-ping() true) { return $this-conn; } } catch (\Throwable $e) { // 掉线后进入重建流程 } $this-close(); } $cfg self::$configs[$this-name]; $newConn new Redis(); $ok $newConn-pconnect($cfg[host], $cfg[port], $cfg[timeout]); if (!$ok) { throw new \RuntimeException(redis pconnect failed: . $this-name); } if ($cfg[auth] ! ) { $newConn-auth($cfg[auth]); } $newConn-select($cfg[db]); $this-conn $newConn; return $this-conn; } private function close(): void { if ($this-conn) { try { $this-conn-close(); } catch (\Throwable $e) { // 忽略关闭异常 } $this-conn null; } } }逻辑上做三件事第一static $instances只是当前请求内的单例缓存真正连接复用靠的是扩展内部持久连接池第二每次拿连接前用ping()做活性探测避免拿到已经断掉的连接第三断线后调用close()主动关闭旧连接再重新 pconnect。这个重连思路来源于一个血泪教训Redis 服务端重启后FPM worker 里的旧连接在 TCP 层面已经死了但 PHP 侧不知道直到第一次get报错才发现。加上 ping 探测后问题消失代价是每次请求多一次 RTT。3.3 pconnect 的 4 个必调参数以及它们的真实含义php-redis 的 pconnect 方法有几个容易忽略的参数我把最常调的说一下参数常见取值说明timeout0.5 ~ 2.0秒连接超时不是读写超时。pconnect 下同样生效persistent_id任意字符串同一个 host:port 可以维护多组持久连接用于区分不同业务实例retry_interval100 ~ 500毫秒连接失败后的重试间隔需要配合 timeout 使用仅在部分版本生效read_timeout0 ~ 2.0秒读超时需要在连接建立后通过setOption()单独设置需要注意persistent_id的坑两个不同的persistent_id会生成独立的持久连接。如果业务里既有队列消费者又有普通缓存请求且二者连的是同一个 Redis 实例可以分别指定persistent_id避免 SELECT DB 或认证状态互相影响。如果你不需要隔离不要传这个参数让扩展按host:port复用默认连接。4. pconnect 典型避坑连接串用、认证失效、库残留与连接数失控的五个现场4.1 现象一请求 A SELECT 了 db2请求 B 却读到了 db2 的数据这是 pconnect 最常见的翻车现场。FPM worker 处理完请求 A 后连接留在扩展池里请求 B 被同一个 worker 接管直接复用旧连接但旧连接上还停留在请求 A 设置的 db2导致请求 B 读到的库完全不对。原因不复杂pconnect 复用的是 TCP 连接而select是连接级别的状态。脚本结束不会重置连接状态于是“上一个请求的上下文”泄漏到了下一个请求。解决方式三种按推荐顺序排列第一代码里每次请求前显式执行一次select到目标库第二放弃多库方案一个 Redis 实例只用一个库彻底消除残留问题第三给不同库拆分不同 Redis 实例或不同persistent_id。我用的是第一种——在PRedis::conn()方法里连接建好后每次先select再返回。多一次命令但业务再没出过错。4.2 现象二认证信息在进程复用后出现 NOAUTH 报错某个项目里一个 FPM worker 先处理了带密码连接的业务 A然后同一 worker 又处理了不带密码的业务 B结果 B 报NOAUTH Authentication required。原因是 A 在连接上执行了auth连接被 B 复用时认证态还在但 B 的代码里没有认证逻辑Redis 认为这条连接已经是认证过的反过来却因为 B 没 auth 而拒绝——实际上这个报错更多是相反方向B 的代码执行了auth但用的是 A 的密码密码不一致导致认证失败并破坏连接状态。这里的根本问题同样是连接级状态残留。解决方法是不要在多个业务之间混用同一个持久连接给每个业务实例传独立的persistent_id或者干脆不同业务用不同 Redis 实例。如果非要在同一个连接上处理不同认证唯一的后悔药是每次请求前重新认证但这会让 pconnect 的复用收益大打折扣。4.3 现象三改了 pconnect 后连接数不但没降反而稳定在“进程数 × 请求类型数”有的项目里一个 worker 进程会在一次请求内创建多个 Redis 对象每个对象都调一次 pconnect。由于persistent_id不传时按host:port复用连接数不会爆但如果代码里有人传了不同的persistent_id给不同业务模块同一个 worker 就会在一个 Redis 实例上挂多条持久连接。于是连接数变成worker 数 × persistent_id 数。排查这类问题用两条命令。第一看 Redis 侧redis-cli client list | awk {print $1} | sort | uniq -c | sort -rn | head -20这一步能看到每个客户端地址上的连接数分布。第二看 PHP 进程侧ss -tnp | grep 6379 | awk {print $6} | sort | uniq -c如果每个 PHP 进程都挂着多条 6379 连接基本可以确认 persistent_id 被用岔了。解决方式很简单全项目统一 pconnect 入口persistent_id只按实例维度区分不给业务模块乱传。4.4 现象四Redis 服务端重启后pconnect 拿到的是死连接某次 Redis 因内存告警被运维重启之后接口随机出现Connection refused和read error on connection。这是因为 FPM worker 里还保持着旧的持久连接但服务端已经断开TCP 连接处于半开状态。客户端第一次请求往往不报错要等到 socket 读写触发 RST 才暴露。解决思路已经在第 3 章的封装里写了每次拿连接前用 ping 做探测。但也要知道 ping 本身有开销如果每次都 ping性能会受影响。折中做法是设置一个连接对象的有效期比如 60 秒内首次使用时 ping 一次之后直接复用或者捕获到RedisException时再做重连。// 捕获异常后强制重连一次再失败则抛出 try { $result $redis-get(key); } catch (\RedisException $e) { $this-close(); $redis $this-conn(); $result $redis-get(key); }这里的逻辑是异常发生后先关闭旧连接再通过conn()重新建连然后重试一次业务命令。注意close()会尝试关闭扩展池里的持久连接只有真正关闭成功后重建才有意义。4.5 现象五长连接数量在你以为释放了之后依然稳如磐石有些开发者在测试环境手动执行$redis-close()然后观察connected_clients发现连接数没有变化。原因是php-redis 的持久连接在close()时可能只是标记为待关闭真正释放要等到该连接被扩展池淘汰或进程退出。这是扩展内部的引用计数和连接复用机制决定的不是你的代码没生效。确认连接是否真正关闭最可靠的方法是看 FPM worker 进程是否退出。可以这样验证# 观察某个 worker pid 的 tcp 连接数 ss -tnp | grep php-fpm-pid | grep 6379 # 然后 kill php-fpm-pid再看连接是否消失 kill php-fpm-pid ss -tnp | grep 6379 | grep php-fpm-pidworker 退出后连接随之消失这是 pconnect 的兜底机制。所以如果想让连接数快速下降不要靠代码逻辑挨个 close直接重启 PHP-FPM 最干净。5. 常驻进程下的 pconnectSwoole 场景的连接归属与连接池隔离5.1 为什么 Worker 进程里 pconnect 才有真正的复用价值PHP-FPM 下 pconnect 的收益是“连接数收敛”但代价是每次请求都多一次 ping 探测、要处理状态残留。到了 Swoole 这类常驻框架里情况完全不同Worker 进程本身不销毁pconnect 建立的连接可以被同一个 Worker 无限次复用不需要每次请求都做 ping也不需要担心连接被“归还”到扩展池后状态串掉。从这个角度看pconnect 本来是为常驻场景设计的PHP-FPM 只是它“顺带能用”的场景。如果你在 Swoole 项目里还在用connect每次请求都重新走 TCP 握手那就白费了常驻进程的优势。常见做法是每个 Worker 进程在启动时创建自己的 Redis 连接进程生命周期内一直使用。5.2 协程模式下不能让连接跨协程串用Swoole 的协程模型给 pconnect 提了一个新问题同一个 Worker 里可能同时有几十个协程在跑如果直接把单个 Redis 连接对象放在 Worker 级别的静态变量里所有协程共用同一个 socket命令交错发送会导致返回错乱这是高并发下最容易出的事故。解决思路是连接池 协程上下文绑定。简单做法是给每个协程分配独立连接?php // 基于协程 ID 绑定连接避免跨协程复用 function getRedisForCurrentCoroutine(): Redis { $cid \Swoole\Coroutine::getCid(); static $connections []; // 注意静态数组在 Worker 内常驻 if (isset($connections[$cid])) { return $connections[$cid]; } $redis new Redis(); $redis-pconnect(127.0.0.1, 6379, 1.0); $redis-select(0); $connections[$cid] $redis; // 协程退出时自动清理连接 \Swoole\Coroutine::defer(function () use ($connections, $cid) { unset($connections[$cid]); }); return $redis; }这个实现的逻辑是用getCid()拿到当前协程唯一 ID每个协程第一次取连接时创建新的持久连接协程结束时通过defer清理。这是最朴素的“协程连接池”不涉及空闲回收、最大连接数限制但足够应对大部分业务。注意pconnect在这里同样创建持久连接但 Worker 内多个协程各自持有独立 socket不会互相干扰。如果业务并发协程数非常大每协程一条连接会导致 Redis 连接数过高。这时候就要用真正的连接池创建一个Swoole\Coroutine\Channel初始化时塞入 N 条连接协程取用时从 Channel pop用完后 push 回去。pconnect 的价值依然体现在“连接初始化后不销毁循环利用”上。5.3 Redis 侧参数建议maxclients 和 timeout 该设多少不管用哪种连接池Redis 服务端的参数都要同步调整。maxclients建议设置为连接池上限 × Worker 数 × 2 100的余量避免压测时直接打满。timeout空闲连接超时建议设置为 0即不主动关闭空闲连接否则 Redis 单方面断开后PHP 侧还留着死连接又回到第 4 章的坑里。另外建议开启tcp-keepalive让系统层定期探测连接活性。Redis 配置里这样调整# redis.conf 或 config set 动态调整 maxclients 10000 timeout 0 tcp-keepalive 60maxclients 10000适合中等规模服务量级可按实际并发上调timeout 0表示不主动回收空闲连接交给连接池自己管理tcp-keepalive 60让 TCP 层每 60 秒发送存活探测报文配合 PHP 侧的 ping 探测基本能覆盖服务端拔线、进程被杀等异常场景。6. 验证 pconnect 是否生效两个命令和一组对照实验一眼看清值不值得改先看连接是否真的复用。用一种最简单的方法连续请求同一个接口多次观察 Redis 侧的连接数变化。# 终端 1观察连接数 watch -n 1 redis-cli client list | grep 127.0.0.1 | wc -l # 终端 2连续压 100 个请求 for i in $(seq 1 100); do curl -s http://127.0.0.1/test.php /dev/null; done如果使用的是 pconnect 且 FPM worker 数固定终端 1 里的连接数会先升到 worker 数附近之后保持不变哪怕压测请求继续增加。如果使用的是 connect连接数会随请求频率锯齿形波动。这个对照足够判断扩展层是否为“长链接”模式。再看延迟差异。做一个只有一次 Redis 读写的最小接口分别用 connect 和 pconnect 跑一轮压测记录平均耗时和连接数峰值。我实际见到的数据是连接数峰值从几百降到几十平均耗时下降约 8% 到 12%但接口整体 RT 因为业务逻辑变长后几乎无感知。这验证了一件事pconnect 主要解决的是“连接数管理”不是接口提速。自己动手复现时带上redis-cli --latency测一轮redis-cli --latency -h 127.0.0.1 -p 6379这个命令能看到 Redis 服务的实时延迟分布。如果某次延迟尖峰恰好发生在 FPM 重启后多半是大量 worker 同时重建连接造成的瞬时抖动连接数越大尖峰越明显。我的习惯是记住一个结论不要用压测 QPS 来评判 pconnect 的价值要看连接数曲线的平滑程度只要连接数不再随请求并发大起大落这个改造就已经值得了。希望帮到你。本文还有配套的精品资源点击获取
