thinkphp不支持redis与数据库跨存储事务，db::transaction仅作用于关系型数据库，对redis无感知；真正可行的是cache-aside模式配合延迟双删策略，即先删缓存、再更新数据库、延迟后二次删缓存，以应对主从同步延迟和并发读写冲突。
ThinkPHP 本身不支持 Redis 事务与数据库事务的跨存储联合提交，Db::transaction 只管 MySQL/PostgreSQL 等关系型数据库，对 Redis 完全无感知。想靠一个 Db::transaction 包住 DB 写 + Redis 操作来“原子性保证一致性”，是行不通的。
ThinkPHP 的 Db::transaction 对 Redis 无效
很多人误以为在 Db::transaction 回调里同时操作数据库和 Redis 就能“一起成功或一起失败”。但 Redis 操作不受 PHP 层事务控制——它既不参与数据库的 ACID，也没有自动回滚机制。哪怕数据库回滚了，Redis 里删掉的缓存、写入的值、自增的计数器，全都还在。
-
Db::transaction内部只调用 PDO 或 MySQLi 的beginTransaction/commit/rollback，和 Redis 客户端（如think-redis或phpredis）完全解耦 - Redis 的
MULTI/EXEC是单机原子命令组，仅限于同一 Redis 实例内的多个 key 操作，不能跨到 MySQL - 即使你手动在回调里调用
$redis->multi()->set(...)->del(...)->exec()，它也只保证自己那几条命令的原子性，和数据库状态无关
真正可行的 Redis + DB 一致性策略：Cache-Aside + 延迟双删
在 ThinkPHP 项目中，最务实、线上验证最多的方式仍是 Cache-Aside（旁路缓存），配合“先删缓存 → 写 DB → 延迟再删缓存”这个组合拳，而非强行套事务。
- 写逻辑示例（简化版）：
try { // 1. 先删 Redis 缓存（让旧数据失效） $redis->del('user:1001'); // 2. 更新数据库（走 Db::transaction 保障 DB 侧一致性） Db::transaction(function () { Db::name('user')->where('id', 1001)->update(['name' => 'Alice']); Db::name('profile')->where('uid', 1001)->update(['bio' => 'dev']); }); // 3. 延迟 100–500ms 后再次删除（覆盖可能因主从延迟、重试等导致的旧值回写） usleep(300000); // 300ms $redis->del('user:1001'); } catch (\Exception $e) { // 记录日志，必要时触发补偿任务（如 MQ 重试或定时扫描） Log::error('User update failed, redis cache may be stale: ' . $e->getMessage()); throw $e; } - 为什么删两次？第一次删是防止更新过程中有并发读请求把旧数据又刷进缓存；第二次删是防数据库主从同步延迟（比如从库还没收到 binlog，此时有读请求打到从库+缓存重建，就会塞回旧值）
- 不要用“先写 DB 再更新 Redis”——更新 Redis 失败会导致缓存永远滞后，且无法自动恢复；而“删缓存”失败影响小，下次读自然重建
高并发下必须加分布式锁防缓存击穿/重建竞争
当大量请求同时发现 user:1001 缓存缺失，又都去查 DB 并试图写缓存，会造成数据库压力激增，还可能因执行顺序问题写入不一致的数据。
- 用
SETNX+ 过期时间实现轻量锁：$lockKey = 'lock:user:1001'; if ($redis->set($lockKey, 1, ['nx', 'ex' => 10])) { try { // 查 DB，写缓存 $data = Db::name('user')->find(1001); $redis->setex('user:1001', 3600, json_encode($data)); } finally { $redis->del($lockKey); } } else { // 等待 100ms 后重试，或直接返回空/默认值 usleep(100000); return $this->getUserFromCache(1001); } - 注意：锁过期时间必须大于 DB 查询 + 序列化 + 写入缓存的总耗时，否则可能锁提前释放，导致多个进程同时重建
- 生产环境建议用 RedLock 或 Redisson，避免单点 Redis 故障导致锁失效
最易被忽略的一点：Redis 和 DB 的一致性从来不是“一次编码就能一劳永逸”的事。它依赖你对业务读写比例、主从延迟水位、故障容忍度的判断——比如电商库存更新必须强一致，就该用 Write-Through + 数据库触发器通知 Redis；而用户昵称修改允许秒级延迟，Cache-Aside 足够。别迷信“事务封装”，先想清楚你的场景到底要什么一致性。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
