PHP 8.1 提升 Redis QPS 的关键是绕开阻塞、复用连接、禁用双重序列化、设合理超时与随机 TTL，并协同 OPcache。需启用连接池、关闭 decode_responses、用 serialize 替代 json、防热 key 与雪崩，且 Redis 配置须匹配 PHP 超时行为。
PHP 8.1 的 Redis 缓存要真正提升 QPS，关键不在“连上就行”，而在于绕开阻塞、复用连接、压减序列化开销，并让缓存命中率和淘汰策略匹配真实请求模式。盲目调 setex 或只装扩展，QPS 很可能原地不动甚至下降。
PHP 8.1 必须启用连接池，不能每次 new Redis()
每次 new Redis() + connect() 都会触发 TCP 握手、认证、命令队列初始化——在高并发下，这比 Redis 本身还慢。PHP 8.1 的 redis 扩展原生支持连接池，但默认不启用。
- 必须在
php.ini中显式开启：添加redis.session.locking_enabled=1（会话场景）或更通用的redis.clusters.seeds=（集群）；单机则直接用Redis::class的连接池封装 - 推荐写法：
$pool = new \RedisArray(['127.0.0.1:6379']); // 自动负载与故障转移<br>$redis = $pool->get('user:1001'); - 若用原生
Redis实例，务必复用：全局单例或 DI 容器注入，禁止在函数内new
避免 JSON 序列化 + decode_responses 双重开销
PHP 8.1 默认开启 decode_responses=1（尤其宝塔/一键安装环境），而业务层又习惯 json_encode/json_decode，等于对同一份数据做两次解析——实测可吃掉 15%~20% 的 CPU 时间，QPS 直接打七折。
- 关闭客户端自动解码：
$redis = new Redis();<br>$redis->connect('127.0.0.1', 6379, 1.0, null, 0, 1.0); // 最后一个参数是 read_timeout，设为 float 强制跳过 decode - 改用
hSet/hGetAll存结构化数据，避免json_encode；纯字符串值直接set/get，不碰序列化 - 若必须存数组，用
serialize()比json_encode()快 30%，且 PHP 原生反序列化无额外依赖
Redis 配置必须匹配 PHP 8.1 的超时行为
PHP 8.1 的 fpm 默认 request_terminate_timeout=30s，但 Redis 默认 timeout=0（永不断连），一旦网络抖动或 Redis 响应慢，PHP 进程会卡满 30 秒才释放，QPS 断崖下跌。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
立即学习“PHP免费学习笔记（深入）”；
- 服务端强制设置：
timeout 5（单位秒）+tcp-keepalive 60，防止连接假死 - PHP 端连接必须带超时：
$redis->connect('127.0.0.1', 6379, 0.5)（连接超时 500ms），setOption(Redis::OPT_READ_TIMEOUT, 1.0)（读超时 1s） - 禁用
redis.conf中的save指令，改用appendonly yes+aof-rewrite-incremental-fsync yes，避免 bgsave 卡主线程
缓存键设计要防穿透、防雪崩、防热 key
PHP 8.1 下的高并发请求很容易把某个 get('user:'.$uid) 打成热 key，Redis 单线程扛不住；若多个 key 同时过期，还会引发雪崩。
- 加随机 TTL 偏移：
$ttl = 3600 + rand(0, 600)，避免整点集体失效 - 热 key 拆分：比如
user:1001:profile、user:1001:stats分开存，而不是全塞进一个user:1001Hash - 穿透防护：查不到时写空值
setex('user:999999', 60, 'NULL')，注意空值也得设 TTL，否则占内存 - 慎用
keys *、hgetall等全量扫描命令——PHP 8.1 的 JIT 加速对这类 O(n) 操作无效，反而更容易触发慢日志
最常被忽略的一点：PHP 8.1 的 OPcache 和 Redis 缓存不是互斥关系，而是分层协作。OPcache 缓的是脚本字节码，Redis 缓的是运行时数据——两者必须同时启用，且 OPcache 的 opcache.validate_timestamps=0 要配合部署流程，否则代码更新后 Redis 缓存还在用旧逻辑，问题更难定位。
