thinkphp不提供双写一致性机制，需业务层实现cache aside策略：先更新数据库再删缓存，失败需重试并告警；高并发下可延迟双删或基于binlog+消息队列解耦处理。
ThinkPHP 本身不提供双写一致性机制，它只负责把 Redis 当作一个键值存储来用；真正要解决缓存与数据库不一致，得靠你写的业务逻辑和选对策略——不是框架的问题，是你在 Db::update() 之后要不要删 Redis::del()、什么时候删、删失败了怎么办。
先更新数据库再删缓存（Cache Aside）是 ThinkPHP 最可行的写法
这是你在控制器或服务类里最常写的模式，也是风险相对可控的起点：
-
Db::name('user')->where('id', $id)->update($data)成功后，立刻调用$redis->del("user:{$id}") - 不要用
$redis->set()去“更新缓存”，否则并发时容易被旧值覆盖（比如 A 写库慢、B 先 set 缓存，A 后 set 反而写回旧数据） - 删除操作必须放在事务提交之后——如果你用了
Db::transaction()，$redis->del()得写在commit成功之后，否则事务回滚了缓存却删了，下次读就错
删缓存失败时不能静默吞掉错误
常见错误现象：$redis->del() 抛异常或返回 false，但代码没 catch、没重试、也没记录日志，结果缓存一直没删，后续所有读都命中旧值。
- 加简单重试：最多 3 次，每次间隔 10–50ms，用
for ($i = 0; $i del($key)) break; usleep(20000); } - 失败后记日志并触发告警（比如写到
storage/logs/redis-del-fail.log），别依赖“反正缓存会过期”——过期时间设成 1 小时，用户就可能卡 1 小时 - 如果项目已接入消息队列（如 RabbitMQ/Kafka），可以把 key 推入一个
cache_delete_queue，由独立消费者执行删除；ThinkPHP 里只需Queue::push(...)，不耦合主流程
高并发下“删-查-回填-删”窗口期仍存在
即使你严格按“先改库再删缓存”，仍可能遇到：请求 A 删完缓存、还没来得及改库，请求 B 就读库并回填了旧值，A 改库完成，缓存里还是旧的。
- 这不是 ThinkPHP 的锅，是 Cache Aside 的固有缺陷；缓解方式是加延迟双删：第一次删 →
Db::update()→usleep(200000)（200ms）→ 第二次删 - 200ms 不是拍脑袋定的，得看你的 MySQL 主从同步延迟监控值（比如
Seconds_Behind_Master常值是 80ms，那就设 150ms 起步） - 别在控制器里直接
usleep()，应封装成异步任务（think\queue\Job或 Swoole 定时器），避免阻塞 HTTP 请求
Binlog + 消费者才是生产环境更稳的选择
如果你的 ThinkPHP 项目跑在 MySQL 5.7+ 且开了 binlog（binlog_format=ROW），那比手动删缓存更可靠的方式是监听变更：
- 用 Canal/Debezium 订阅 binlog，解析出
UPDATE user SET name=? WHERE id=?这类语句，提取id后发消息到队列 - ThinkPHP 写个消费者命令
php think cache:delete-user，收到消息就执行$redis->del("user:{$id}") - 优势：完全解耦，数据库写成功即算完成；缓存操作失败可无限重试，不影响主链路；还能统一处理多表关联缓存（比如订单更新后连带删用户统计缓存）
复杂点在于部署 Canal 和维护消费者，但一旦跑起来，比在每个 update() 后手写 del() 更少出错——人容易漏删、删错 key、删早或删晚，机器不会。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
