Laravel数据库读写分离权重配置与从库按比例分流详解

在 Laravel 项目中配置数据库读写分离时，你是否遇到过这样的困惑：明明在配置文件中为 read 项设置了多个从库，甚至还精心分配了权重，但实际运行时，查询请求却总是不按“套路”出牌，要么全跑到主库，要么从库的流量分配完全不符合预期？

问题的根源，其实不在于配置语法，而在于 Laravel 框架底层的连接管理逻辑。默认情况下，Laravel 并不原生支持“按权重随机选择从库”这种高级功能，它只提供了两种基础模式：要么固定回退（fallback），要么手动指定连接名。如果你只是简单地把从库列表写成数组，那么所谓的“权重”字段根本不会被框架读取，自然也就无法实现按比例分流。

为什么 read 和 write 连接会走错库？

首先需要明确一点：配置了多个 read 主机，并不意味着你的读操作就一定会自动、智能地分配到从库。这里有几个关键机制在起作用：

• 读写上下文判定：像 DB::select() 或 User::query()->get() 这类读操作，只有在当前数据库会话中没有活跃的写事务时，Laravel 才会尝试为其分配 read 连接。
• “粘性”连接的影响：一旦前面执行过 DB::transaction() 或模型的 save() 等写操作，后续所有的数据库操作（包括读）都会被“粘”在主连接上，除非你显式地使用 on('read') 来指定。
• 默认的负载均衡策略：即使你的 read 配置是一个包含多个主机的数组，Laravel 默认采用的也是简单的“轮询”策略，它完全无视你手动添加的 weight 字段。所以，感觉流量分配“不听话”，其实是框架的默认行为。

怎么让从库真正按权重分流？

既然原生不支持，要实现按权重的分流，就必须自己动手，接管 read 连接的选择逻辑。一个相对轻量且优雅的方案，是利用配置项支持闭包的特性，动态地返回连接名。

具体操作路径如下：

• 改造配置结构：在 config/database.php 的数据库配置（例如 mysql）中，将 read 键的值从一个静态数组，改为一个返回连接名的 function() 闭包。
• 实现权重算法：在闭包内部，使用 mt_rand() 结合权重配置进行概率抽样，最终返回选中的具体连接名（如 'mysql-read-1'）。
• 定义独立连接：你需要将每个权重不同的从库，在 connections 数组下定义为独立的连接配置（如 mysql-read-1, mysql-read-2），确保它们拥有相同的 database、username 等核心参数，但 host 指向不同的从库服务器。
• 谨慎处理 sticky：这个配置项至关重要。务必将其设为 false，才能解除读写操作的强制绑定，让读操作有机会分离到从库。如果设为 true，则会强制同一请求内的所有数据库操作都使用主库连接。

下面是一个核心的配置示例片段：

'mysql' => [
    'read' => function () {
        // 定义连接名与权重的映射
        $weights = ['mysql-read-1' => 70, 'mysql-read-2' => 30];
        $rand = mt_rand(1, 100);
        $sum = 0;
        foreach ($weights as $name => $weight) {
            $sum += $weight;
            if ($rand <= $sum) return $name;
        }
        // 兜底返回
        return 'mysql-read-1';
    },
    'write' => [...], // 写连接配置
    'sticky' => false, // 必须为false
],

DB::connection('mysql') 为什么还是连主库？

这个问题很常见，也容易让人误解。当你直接调用 DB::connection('mysql') 时，你获取的是名为“mysql”的这个逻辑连接组。Laravel 在首次解析这个连接组时，会根据上下文（通常是默认的写上下文）缓存一个具体的 PDO 连接实例。如果此时没有触发读操作判定，它自然就缓存了主库的连接。

要理清这里面的门道，可以关注以下几点：

• 显式指定与自动分发：使用 DB::connection('mysql-read-1') 可以绕过自动分发，直连特定从库，但这也就失去了权重分流的意义。我们通常希望的是通过标准读方法（如模型查询）自动触发分发。
• 确保干净的读上下文：要让自动读分发生效，需确保查询前没有开启事务，也没有执行过任何写操作。同时，注意检查中间件，有些权限验证中间件会提前执行用户查询，意外地“粘住”了主库连接。
• 诊断连接状态：如果怀疑连接错了库，一个实用的调试方法是打印当前 PDO 实例的连接状态：DB::connection()->getPdo()->getAttribute(PDO::ATTR_CONNECTION_STATUS)，这能帮你确认实际连接的数据库主机。

从库延迟导致数据不一致怎么办？

实现了权重分流，另一个无法回避的挑战就是主从延迟。分流本身不解决延迟问题，反而可能让不一致的情况随机出现——你无法预知哪一次读请求会命中那个延迟较高的从库。

面对这个问题，业务上需要接受“最终一致性”的现实，技术上则可以进行分级管控：

• 强一致性读：对于刚写入就必须立刻读取的场景（如支付成功页），应显式使用 DB::connection('mysql-write') 或链式调用 ->useWritePdo() 方法，强制走主库。
• 弱一致性读：对于列表页、统计报表等非关键读操作，可以放心交给权重分流，容忍秒级的数据延迟。
• 避免依赖从库特定变量：切勿在从库连接上依赖 last_insert_id 或 @@binlog_gtid_executed 这类变量，它们在从库上可能不可靠或无意义。
• 动态权重调整：监控各从库的 Seconds_Behind_Master（主从延迟秒数）。当某个从库延迟超过阈值时，可以通过配合服务发现或配置中心热重载，临时将其从权重池中剔除或降低其权重。

说到底，权重分流是一种流量分配的技术手段，而非数据一致性方案。要真正保证强一致性，关键在于收口业务层的读路由逻辑，由开发者明确指定特定查询的读写路径，而不是完全寄希望于框架去自动判断每一条 SQL 该去哪台机器。