LaravelRedis缓存失效与会话清理解析

本文深入剖析了 Laravel 中 Redis 缓存“看似失效”的典型误区——表面是 Cache::put() 写入后 Redis 查无此 key 或出现意外 DEL 命令，实则源于 CACHE_DRIVER=file 配置导致缓存根本未走 Redis，以及会话垃圾回收（GC）在 Redis DB 0 中清理 session key 时被误判为缓存删除；文章不仅一针见血指出配置错配与连接混用（cache 连接 vs session 连接、DB 1 vs DB 0）两大根源，更提供从 .env 驱动切换、REDIS_CACHE_DB 显式声明、cache.php 连接精准绑定到多数据库隔离验证的完整落地方案，助你彻底告别缓存幻觉，让每一次 Cache::put() 都真实、可查、可控。

本文详解 Laravel 中因 CACHE_DRIVER=file 导致 Redis 缓存未启用，以及 Cache::put() 表面“失效”实为 Redis 会话垃圾回收（GC）误判的根源，并提供完整配置修复方案。

本文详解 Laravel 中因 `CACHE_DRIVER=file` 导致 Redis 缓存未启用，以及 `Cache::put()` 表面“失效”实为 Redis 会话垃圾回收（GC）误判的根源，并提供完整配置修复方案。

在 Laravel 应用中使用 Cache::put('Session_Token: ' . $getSessionID, true, 900) 却发现 Redis 中查不到对应 key（执行 keys * 无结果），甚至 redis-cli monitor 显示出意料之外的 DEL 命令——这并非缓存逻辑错误，而是典型配置错配与机制误解共同导致的现象。根本原因有二：缓存驱动未切换至 Redis，以及Redis 会话 GC 与缓存操作共用连接但分属不同数据库，造成监控混淆。

? 根本原因剖析

1. 缓存驱动被覆盖为 file
   .env 中明确配置了：

   CACHE_DRIVER=file

   这将完全绕过 Redis 缓存系统。即使 config/cache.php 中 redis 驱动已定义、config/database.php 中 cache 连接也已声明，Laravel 仍会优先使用 file 驱动——此时 Cache::put() 实际写入的是本地文件（storage/framework/cache/data/），与 Redis 完全无关。这也是 keys * 在 Redis 中查不到任何缓存 key 的直接原因。

2. DEL 命令来自 Session GC，而非 Cache 操作
   monitor 输出中的：

   "DEL" "laravel_database_laravel_cache:9C5AGmh99tVzG9Sc0OTWygfh1pXvFEnCg1Ckr4nB"

   看似是缓存 key 被删除，实则该 key 是 Laravel Session 使用 Redis 存储时生成的 session ID key（前缀 laravel_database_ 来自 REDIS_PREFIX，laravel_cache: 是 session 默认前缀）。此 DEL 由 StartSession 中间件内置的「垃圾回收彩票机制」（Garbage Collection Lottery）触发：每 100 次请求约有 1 次概率执行 SessionHandler::gc()，清理过期 session。它操作的是 SESSION_CONNECTION（即 database => 0 的 default 连接），与缓存所用的 cache 连接（database => 1）物理隔离。

✅ 正确配置步骤

步骤 1：启用 Redis 缓存驱动

修改 .env，将缓存驱动切换为 redis：

CACHE_DRIVER=redis

⚠️ 注意：CACHE_DRIVER 必须为 redis，否则 Cache:: 所有方法均不走 Redis。

步骤 2：显式声明 REDIS_CACHE_DB

.env 中补充缓存专用数据库编号（需与 config/database.php 中 cache.database 一致）：

REDIS_CACHE_DB=1

确保 config/database.php 中 cache 连接保持 database => env('REDIS_CACHE_DB', '1')。

步骤 3：验证连接分离（关键！）

确认 config/cache.php 正确指向 cache 连接：

'redis' => [
    'driver' => 'redis',
    'connection' => 'cache', // ← 明确使用 cache 连接（DB 1）
    'lock_connection' => 'default', // ← 会话锁等仍用 default（DB 0）
],

此时：

• Cache::put() → 写入 Redis DB 1
• Session → 读写 Redis DB 0
  二者彻底解耦，monitor 中的 DEL 将只出现在 DB 0，不再干扰对 DB 1 的观察。

步骤 4：调试与验证命令

# 查看 DB 1 中的缓存 key（需先 SELECT 1）
redis-cli -a laravel SELECT 1 && KEYS "*Session_Token*"

# 或直接指定 DB 查询
redis-cli -a laravel -n 1 KEYS "*Session_Token*"

# 查看 DB 0 中的 session key（用于对比）
redis-cli -a laravel -n 0 KEYS "*laravel_cache*"

? 补充说明与最佳实践

• *不要依赖 `keys 全局扫描**：生产环境应禁用；推荐用带前缀的KEYS "Session_Token:*"或改用SCAN` 命令。
• 会话 GC 不可禁用，但可调优：通过 session.lifetime 和 session.cookie_lifetime 控制过期时间，降低 GC 频率；如需关闭（仅开发），可重写 StartSession 中间件，但不推荐。
• 密码安全提示：.env 中 REDIS_PASSWORD=laravel 属弱密码，生产环境务必更换并使用强密码+网络 ACL。
• 配置热更新：修改 .env 后，运行 php artisan config:clear 清除配置缓存，避免旧配置残留。

完成上述配置后，再次执行登录逻辑，Cache::put() 将真实写入 Redis DB 1，且 redis-cli -n 1 KEYS "*" 可稳定命中目标 key——从此告别“缓存消失”的幻觉，让每一行 Cache:: 代码都精准落地。

到这里，我们也就讲完了《LaravelRedis缓存失效与会话清理解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！