ThinkPHP事务核心是Db::transaction，确保数据库操作原子性与一致性，但仅限InnoDB等支持事务的数据库，无法覆盖Redis等外部存储；正确用法为闭包内执行同连接DB操作，异常自动回滚，且需避免耗时任务。
ThinkPHP 的事务处理核心是 Db::transaction，它能确保数据库操作的原子性与一致性，但仅作用于关系型数据库（如 MySQL InnoDB），对 Redis 等外部存储完全无感知。想靠一个事务包裹 DB 更新 + Redis 缓存操作来实现“跨存储一致”，在技术上不可行。
Db::transaction 的正确用法
这是 ThinkPHP 官方推荐、最简洁安全的方式：
- 自动开启事务、捕获异常、失败时自动回滚，无需手动调用
startTrans/rollback - 所有数据库操作必须在闭包内完成，且使用同一数据库连接
- 要求表引擎支持事务（如 MySQL 必须用 InnoDB，MyISAM 不支持）
- 事务体应尽量轻量，避免耗时操作（如 HTTP 请求、文件读写、长循环）
Redis 与数据库不兼容事务的真相
很多人误以为在 Db::transaction 回调里同时删缓存、改数据库就能“一起成功或一起失败”。但事实是：
- Redis 操作不受 PHP 层事务控制，没有回滚机制；数据库回滚了，Redis 里的
del或set依然生效 -
$redis->multi()->exec()只保证 Redis 单实例内多命令的原子性，和数据库状态无关 - ThinkPHP 的事务管理器与 Redis 客户端（如
think-redis）完全解耦，不存在跨存储协调能力
真正可行的一致性方案：Cache-Aside + 延迟双删
在 ThinkPHP 项目中，兼顾可靠性与落地性的主流做法是旁路缓存模式配合两次删除：
立即学习“PHP免费学习笔记（深入）”；
- 第一步：先删 Redis 缓存——让并发读请求无法命中旧值，避免脏数据回写
- 第二步：再执行 Db::transaction 更新数据库——保障 DB 层强一致性
- 第三步：延迟 100–500ms 后再次删 Redis——覆盖主从同步延迟、读库回源、重试等导致的旧值残留
示例逻辑中，usleep(300000) 并非最佳实践，生产环境建议改用消息队列（如 RabbitMQ）或延时任务触发二次清理，避免阻塞主线程。
增强一致性的辅助手段
单靠事务不够，还需组合其他机制：
- 数据库约束：主键、唯一索引、外键、CHECK 条件，由存储层兜底校验
- 应用层校验：事务内做业务规则判断（如余额是否充足），失败则抛异常触发回滚
- 乐观锁：对高频更新字段加 version 或 timestamp，避免丢失更新
- 幂等设计：关键接口（如支付回调）带唯一业务 ID，重复请求只处理一次
- 日志与补偿：记录事务关键步骤，失败后可通过定时扫描或 MQ 触发修复任务
