ThinkPHP数据库读写分离后如何处理缓存_主从同步延迟

刚写入就查不到数据，很多开发者的第一反应是缓存没刷新。但先别急着去清Redis，问题很可能出在数据库层——你查的根本就不是刚写入的那个库。

刚写入就查不到，不是缓存问题，是读库选错了

这个场景太典型了：Db::name('order')->insert($data) 之后，紧接着执行 Db::name('order')->where('sn', $sn)->find()，结果返回空。直觉上会怀疑缓存，但真相往往是，那条 find() 查询被ThinkPHP默认路由到了从库，而主库刚写入的数据，还没来得及同步过去。

问题的根源在于，框架的读写分离策略是机械的：它只根据SQL语句的类型（SELECT走从库，INSERT/UPDATE/DELETE走主库）做路由，完全不了解你的业务上下文。它不会因为你上一条语句是插入，就“聪明地”把下一条查询切回主库。

• 先诊断，后下药：遇到这种情况，别急着去清缓存或设置缓存过期时间。先用 getLastSql() 看看查询日志，确认SQL最终执行在哪台服务器上。如果连接地址显示的是从库，那问题就明确了。
• 别用缓存掩盖问题：试图在模型查询里加上 ->cache(true) 来绕过延迟，是饮鸩止渴。这只会让“查不到”的错误结果被缓存起来，问题更持久。
• 最直接的解法：对于这类强一致性查询，显式指定主库是最稳妥的：Db::master()->name('order')->where('sn', $sn)->find()。

ThinkPHP 的 read_master 配置容易被误用

看到配置项 'read_master' => true，很多人会以为找到了“万能钥匙”——写完自动切主库读。但它的实际行为需要仔细理解：只要在当前请求生命周期内，对某张表执行过写操作，那么后续对该表的所有读操作，都会被强制路由到主库。

这个机制听起来合理，但藏着两个不大不小的坑：

• 作用范围仅限于“同一张表”。比如你先 insert 了 user 表，紧接着去关联查询 user_profile 表，后者依然会走从库，可能导致关联数据不一致。
• 按请求生命周期生效，而非按事务。如果一个请求里混杂了多个不相关的写操作，会导致整张表后续的所有读都被锁在主库，无形中增加了主库压力，失去了读写分离的意义。
• 无法解决跨请求场景。典型例子是用户注册（请求A写入）后跳转到个人中心（请求B读取），read_master 配置在新的请求里是无效的。

缓存层怎么配合读写分离才不放大延迟

引入Redis做缓存，本意是提升性能、缓解数据库压力。但如果缓存策略和数据库读写路由配合不当，反而会固化数据不一致的状态，让问题更难排查。

一个典型的错误模式是：写主库后删除缓存，但下一次读请求被路由到从库，查到了尚未同步的旧数据，然后这个旧数据又被写回了缓存——这就形成了一个“脏缓存闭环”。

• 强一致性场景的缓存策略：对于订单详情这类数据，缓存逻辑应该与主库查询绑定。例如，查询 order:123 时，先通过 Db::master() 从主库读取，再将结果写入缓存。而不是简单地删除缓存后，放任下一次查询可能从从库加载旧数据。
• 慎用“查库回填”的懒加载模式：对于关键业务路径，应避免完全依赖“查不到缓存 → 读从库 → 回填缓存”的模式。可以考虑改为“写主库 → 同步写缓存 → （异步）更新从库对应缓存”的主动更新策略。
• 缓存TTL设置需谨慎：不要简单地将缓存失效时间设置为“略大于主从同步延迟”。MySQL的 Seconds_Behind_Master 只是一个瞬时指标，网络抖动或一个大事务都可能导致同步延迟出现尖峰。更稳妥的做法是结合业务监控动态调整。

事务内读写天然一致，但别指望它覆盖所有场景

在事务内部，一致性是有保障的。例如：

Db::transaction(function () {
    Db::name('user')->insert($u);
    $u = Db::name('user')->where('id', $id)->find();
});

这段代码里的 find() 必定走主库，且能查到刚插入的数据。这是事务的特性决定的。

然而，事务并非银弹，它的局限性很明显：

• 资源消耗：事务会占用主库连接，在高并发场景下，容易导致数据库连接池被迅速打满。
• 作用域有限：它只对当前事务块内的操作有效。对于跨服务调用（例如支付回调写库后，通过另一个HTTP请求查询），事务早已结束，read_master 或 master() 都不再适用。
• 框架限制：ThinkPHP的事务通常不支持跨不同数据库连接（如主库和从库）混合操作。在事务内尝试同时写主库和读从库，可能导致错误或未定义行为。

真正棘手的，往往是那些“写操作在一个请求，读操作在另一个请求”的分布式场景。这时候，依赖数据库层面的机制已经不够了，需要借助业务标识（如订单号透传）、请求上下文传递，或者在业务设计上就接受最终一致性，通过消息队列等机制进行补偿。缓存，只是这个复杂拼图中的一块，远非全部答案。