生产环境优先用phpredis（c扩展），性能比predis高30%–50%，原生支持连接池、管道、lua脚本和集群，且setex()等操作原子安全；predis适合开发或容器化初期，无需扩展但不支持连接复用。
直接用 phpredis 扩展连接单机 Redis 就能解决 80% 的缓存性能问题；集群不是默认选项，而是当单节点内存或吞吐见顶、且业务已出现超时或连接堆积时才需引入。
怎么选客户端：phpredis 还是 Predis？
生产环境优先用 phpredis（C 扩展），它原生支持连接池、管道、Lua 脚本和集群模式，性能比纯 PHP 实现的 Predis 高 30%–50%，尤其在高并发短连接场景下更稳定。
Predis 适合开发或容器化部署初期——无需编译扩展，composer require predis/predis 即装即用；但它不支持连接复用，每个请求新建 TCP 连接，容易触发 TIME_WAIT 堆积。
关键差异点：
-
phpredis的setex()和get()是原子操作，Predis的同名方法底层仍是两步（先set再expire），极端情况下可能缓存写入但过期失败 -
phpredis支持Redis::SERIALIZER_IGBINARY，序列化效率比json_encode()高 2–3 倍，且兼容 PHP 8.3+ 的严格类型 - 若项目已用 Laravel，别自己封装——直接配
CACHE_DRIVER=redis，它底层自动适配phpredis或Predis
缓存键设计必须带业务前缀和分隔符
别写 $redis->set('user_123', $data)。这种键无法批量清理、易冲突、监控时看不出来源。
正确格式是 模块:资源类型:id，例如：
-
user:profile:123（用户资料） -
product:detail:sku-789（商品详情） -
config:site:theme（配置项）
这样做的实际好处：
- 用
KEYS user:profile:*可临时扫描，但生产禁用；真正该用的是SCAN+ 游标遍历 - 配合
EXPIRE或SETEX设置 TTL 时，前缀能帮你快速识别哪些键该设长过期（如配置）、哪些该设短过期（如会话） - Redis 监控工具（如 RedisInsight）按前缀分组后，一眼看出哪个模块缓存命中率低
为什么 setex() 比 set()+expire() 更安全？
因为 setex() 是 Redis 原生命令，一次网络往返完成「写值 + 设过期」，不存在中间状态。
而手动调用 $redis->set($key, $val) 再 $redis->expire($key, $ttl) 有风险：
- 如果
set成功但expire失败（网络闪断、Redis 瞬间满载），这个键就变成永不过期的“僵尸缓存” - 在主从复制场景下，
set和expire可能被拆成两条命令发往从库，造成从库上键存在但无过期时间 - 某些 Redis 版本（
6.0之前）对expire命令的响应码处理不一致，PHP 客户端可能误判成功
所以一律用 setex() 或 set($key, $val, ['EX' => $ttl])（phpredis 4.3+ 支持数组参数写法）。
集群环境下哪些操作要特别小心？
Redis 集群强制要求：同一个命令里所有 key 必须落在同一个哈希槽。否则会返回 CROSSSLOT Keys in request don't hash to the same slot 错误。
这意味着这些操作在集群中不可用：
-
MGET user:1 user:2 user:3—— 如果这三个 key CRC16 后模 16384 得到不同槽号，直接报错 -
KEYS user:*—— 集群不支持全局 key 匹配，必须用SCAN在每个节点单独扫 - 跨 key 的 Lua 脚本（比如同时读
user:1和user:1:stats）—— 必须确保两个 key 的槽位一致，通常靠在 key 后加{tag}强制路由，例如user:{1}:profile和user:{1}:stats
简单规避方式：用 phpredis 的 rawCommand() 手动发 SCAN 到各节点，或改用单实例 Redis 处理需要多 key 原子性的逻辑。
缓存不是加了就完事——最常被忽略的是「缓存穿透」：当大量请求查一个根本不存在的 user:9999999，每次都会击穿到数据库。解决方案不是只加空值缓存，而是得配合布隆过滤器或 SETNX 互斥锁，否则并发一上来，空值缓存本身也会被反复覆盖失效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
