laravel默认redis配置扛不住高并发，因连接池仅2个、无复用与健康检查、未启用pipeline、缺乏集群高可用及cache::remember()的惊群效应。
为什么Laravel默认Redis配置扛不住高并发
直接用 CACHE_DRIVER=redis + 默认 redis 连接配置，在 QPS 超过 2000 后就容易出现连接超时、响应毛刺甚至缓存穿透。根本原因不是 Redis 本身不行，而是 Laravel 的默认 Redis 客户端（Predis 或 PhpRedis）未启用连接复用、无健康检查、不支持自动故障转移，且单点连接池容量固定。
典型现象包括：Connection refused、read error on connection、大量 Cache::get() 返回 null 却不触发回源逻辑——这往往是因为连接池耗尽后请求被静默丢弃，而非抛异常。
- 默认连接池大小是 2，远低于高并发场景所需（参考公式：连接数 ≈ 峰值 QPS × 平均 RT × 1.2）
- 未启用 pipeline，高频小 key 读写产生大量网络往返
- 未配置哨兵或 Cluster，主节点宕机即全量缓存失效
-
Cache::remember()在缓存 miss 时若数据库查询慢，会阻塞整个连接，加剧连接池饥饿
Laravel 中启用 Redis Cluster 的关键配置点
Redis Cluster 是目前最稳妥的高可用方案，但 Laravel 原生不直接支持 multi-node routing，必须通过配置绕过 default 连接，显式启用 clusters。
核心动作不是改 .env，而是重写 config/database.php 的 redis 块：
'redis' => [
'client' => 'phpredis',
'clusters' => [
'cache' => [
[
'host' => '192.168.1.10',
'port' => 7000,
'password' => env('REDIS_PASSWORD'),
'database' => 0,
],
[
'host' => '192.168.1.11',
'port' => 7001,
'password' => env('REDIS_PASSWORD'),
'database' => 0,
],
// 至少 3 主节点，建议 3 主 3 从
],
],
'options' => [
'cluster' => 'redis',
],
],
然后在 config/cache.php 中确保：
'default' => 'redis'-
'stores.redis.connection' => 'cache'（不是default） - 删掉
'stores.redis.host'等单点字段，避免被 fallback 覆盖
验证是否生效：php artisan tinker 执行 Cache::store('redis')->put('test', 'ok', 60)，再用 redis-cli -c -h 192.168.1.10 -p 7000 get test 查看是否能命中 —— Cluster 模式下 key 会按 slot 自动路由，不能用普通 redis-cli 直连单节点查。
Cache::remember() 在高并发下的陷阱与替代写法
Cache::remember() 看似简洁，但在高并发缓存击穿场景下会引发“惊群效应”：多个请求同时发现缓存 miss，全部涌向数据库执行闭包，造成瞬时 DB 压力飙升。
这不是 Laravel Bug，而是语义设计使然 —— 它不做分布式锁，只做本地判断。
- 避免在秒杀类接口中直接用
Cache::remember('stock_123', 30, fn() => Db::table(...)) - 改用带原子锁的模式：先
Cache::lock('stock_123:lock', 10)->get()，成功才执行数据库查询并set()缓存 - 对计数类数据（如浏览量），用
Redis::incrby('article:123:view', 1)替代读-改-写，避免竞态 - 批量 key 查询优先用
Cache::many(['a','b','c'])或底层Redis::mget(['a','b','c'])，而非循环get()
注意：Cache::lock() 依赖 Redis 的 SET key value NX EX 原子指令，仅在 Redis 驱动下有效，且需确保 Redis 版本 ≥ 2.6.12。
本地缓存 + Redis 双层结构怎么避免脏读
加一层 Caffeine 或 Laravel 内置 array 缓存能抗住突发流量，但极易出现本地缓存未及时失效导致的数据不一致。
关键不在“怎么设”，而在“怎么清”：
- 禁止对同一业务 key 同时写入本地缓存和 Redis —— 应由 Redis 作为唯一可信源，本地缓存仅作 read-only 副本
- 更新数据时，先
Redis::del('user:123')，再Cache::store('array')->forget('user:123')，顺序不能反 - 利用 Laravel 的 cache tags（仅 Redis 支持）：如
Cache::tags(['user', 'profile'])->put('123', $data, 300)，后续可一键Cache::tags(['user'])->flush() - 对强一致性要求高的场景（如库存），跳过本地缓存，直连 Redis Cluster，用
Redis::eval()执行 Lua 脚本保证原子性
真正容易被忽略的是缓存键命名空间污染：比如 user:123 和 user_profile:123 在不同模块里各自管理，删除时漏掉一个，就会埋下脏数据隐患。建议统一用 cache_key('user', 123, 'profile') 类辅助函数生成键名，从源头收敛。
