订单系统读写分离实战：从主从复制到动态数据源路由-AI智能范式网

订单系统读写分离实战：从主从复制到动态数据源路由

谈国平·2026-10-14·阅读 23 GEO检测（免费）

MySQL读写分离订单系统

|难度：普通|阅读约 41 分钟

1. 背景梳理：订单系统到底为什么必须做读写分离

1.1 订单数据的两副面孔：读多写少背后的真实压力

做订单系统的朋友应该都有这种感觉：订单表的数据量一上来，最先撑不住的不是写入，而是查询。用户下单只是一瞬间的事，但查订单列表、查订单详情、查物流状态、查历史订单这些操作，几乎是无时无刻不在发生。尤其是一些做电商、外卖、同城配送这类C端业务的项目，用户端的每一个页面刷新，背后都是一串订单相关的查询语句。

我参与过的某个订单系统项目，上线半年后订单量涨到日均百万级别，单库单表在高峰期经常出现CPU打到90%以上的情况。最典型的场景是晚高峰时段，用户集中下单和查单，数据库连接数直接被占满，新请求的SQL全部排队，然后引发连锁反应——应用层连接池等待超时，接口响应从几十毫秒直接飙到几秒，最后连下单这种核心写入路径也被拖垮。

先别急着上分布式数据库或者分库分表，先冷静分析一下瓶颈到底在哪。我用监控工具统计过，这个订单系统的读写比大约在8:2到9:1之间，也就是说，80%以上的数据库压力来自查询。写入量其实不大，单库完全扛得住，真正的问题在于查询把CPU、IO、连接数这些资源吃完了，导致写入也被拖慢。

面对这种"读多写少"的典型场景，读写分离是最直接、成本最低、收益最明显的优化手段。把读流量和写流量从物理上拆开到不同的数据库实例上，各干各的活，谁也不占谁的资源。这就是我想做这个方案的最根本原因。

1.2 单库瓶颈的几个典型信号

判断你的订单系统是否真的需要做读写分离，不用等监控告警，我总结了几个比较典型的信号，命中两三条基本就可以动手了：

数据库CPU在业务高峰期持续超过70%，而写入量其实并不大，大部分SQL都是查询。
慢查询日志里大量出现订单表的查询语句，单次执行时间超过1秒，甚至几秒，但单表数据量还没到千万级别，索引也基本合理。这种情况下，问题往往不是SQL本身，而是CPU和IO资源被抢占了。
数据库连接数经常打满，应用层频繁报"too many connections"。连接数耗尽最常见的原因就是大量慢查询占着连接不释放。
应用层做了缓存，但缓存命中率不高，订单数据变化频繁，缓存经常失效，导致大量请求还是打到数据库。

如果你遇到的是这类情况，分库分表可能还太早，读写分离是更匹配的解决方案。

1.3 读写分离能解决什么，不能解决什么

读写分离的核心思路非常朴素——准备一个主库专门处理写入操作，一个或多个从库专门处理读取操作。通过主从复制机制，主库的写入变更实时同步到从库，应用层通过某种路由规则，把读请求和写请求分发到不同的数据库实例上。

要把它和分库分表区分清楚。读写分离解决的是资源的垂直拆分问题，也就是把同一份数据的读和写压力分开；分库分表解决的是数据的水平扩展问题，把数据本身拆到不同的库和表里。两者不是一回事，也不能互相替代。

这里要非常明确地泼一盆冷水：

记住，读写分离不是万能的。订单系统里那些极度复杂的多表关联查询、聚合统计、报表类查询，读写分离帮不了你。如果业务里有大量这种查询，要么走独立的统计库，要么引入搜索引擎或OLAP组件，别指望读写分离能拯救一切。

另外，读写分离天然会引入主从数据延迟的问题，这对订单系统来说是比较要命的。用户刚下完单，回头查订单列表，如果读到的是还没同步完成的从库数据，那就会出现"订单不见了"的体验。所以，方案设计阶段就必须把延迟容忍策略想清楚，这块后面我细讲。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 方案选型：先想清楚再动手

2.1 两种主流路线的对比：中间件还是应用层

读写分离的落地方式大体上可以分为两大流派。

第一种是数据库中间件方案，比较常见的有开源的ShardingSphere、MyCat，以及各大云厂商提供的数据库代理产品。应用层不感知读写分离的存在，它只需要连接一个逻辑上的代理地址，由中间件负责把请求分流到主库或者从库。应用层的代码几乎不用改，只在配置层面做调整。

第二种是应用层自研方案，在项目代码内部实现多数据源配置和路由逻辑。常见的做法是配置主从两个数据源，通过一个动态数据源组件，在运行时根据操作类型（读还是写）动态切换当前线程使用哪个数据源。技术栈是Java的话，可以用AbstractRoutingDataSource配合AOP注解实现。

两种方案各有各的适用场景。中间件方案的优势是侵入性小，后续如果想平滑升级到分库分表，迁移成本低，而且对团队的技术要求相对没那么高。但劣势也很明显，就是多引入了一层网络代理，多一层依赖，排障链路变长，而且某些中间件在事务处理、复杂SQL兼容性上会踩到坑。

应用层方案的优势是灵活，路由规则完全掌控，不依赖外部代理，性能损耗几乎为零。而且连接是应用直接打到数据库的，定位问题比较直接。劣势就是代码侵入性较大，每个项目都要做一遍接入，后续维护成本也不低，需要团队自己能hold住这套逻辑。

关于性能损耗我要多说一句。很多人在选型时过分在意中间件那零点几毫秒的代理转发开销，但实际上在订单系统这个场景里，网络开销和SQL执行时间才是大头。中间件方案最大的成本不在性能，而在于多了一个故障点。中间件一旦挂了，整个数据库层就全部不可用，这对核心订单链路来说是需要重点考虑的。

2.2 我的选型结论与实际考虑

我最后选择的是应用层自研方案。原因很简单，项目团队对这块技术的掌控力比较强，而且订单系统的路由逻辑相对明确，用AOP实现一套动态数据源路由并不复杂，整体可控性更好。

不过，这里有个大前提——如果你所处的团队对数据库这块的人手不多，运维能力也比较薄弱，我建议你用中间件方案。云数据库自带的读写分离代理功能其实是最省心的，开了主从复制之后，在控制台点一下就能生成一个代理地址，主从切换、故障转移这些运维操作基本被平台接管了。

我的建议是：小团队优先云厂商方案，有专业DBA或后端基础扎实的团队可以考虑应用层自研。先把业务跑稳，再考虑技术上的自由度，技术选型永远服务于业务阶段。

2.3 主从复制的基础：binlog与复制链路

不管是哪条路线，读写分离的基础都是主从复制。只要用MySQL，主从复制的核心机制就是对binlog（二进制日志）的传递和重放。

以我用的MySQL 5.7为例，主库开启binlog之后，所有写操作（INSERT、UPDATE、DELETE）都会按顺序记录到binlog中。从库通过一个IO线程，主动去主库拉取binlog，并将其写入自己的中继日志（relay log）。随后，从库上的SQL线程会按顺序执行中继日志里的SQL，把主库的变更重放到自己的数据上。这样主库和从库的数据就保持了一致。

这里有三个非常重要的细节参数，和后续问题排查直接相关：

binlog_format：我强烈建议设为ROW模式。STATEMENT模式下记录的是SQL语句本身，在主从执行时如果遇到函数、存储过程、非确定性的计算，可能会出现主从数据不一致。ROW模式记录的是行级别的变更细节，一致性最好。
server-id：主库和每个从库都必须设置为不同的唯一值，否则复制链路会冲突。这是一个看起来很基础但经常被忽略的配置。
read_only：从库必须设置为read_only=1，确保应用层如果误把写请求发到从库，会被MySQL直接拒绝。这是保护数据一致性的底线。

主从复制的拓扑结构，最推荐的是一主一从起步，如果你的业务量更大，可以扩展为一主多从，从库挂个两到三台，通过负载均衡分担读压力。但不要搞主主复制，即两个库互为主从。订单这种对数据一致性要求极高的业务，主主复制在冲突处理和故障切换时都比较麻烦，一不小心就把数据弄坏了。

3. 实现过程：把读写两条路走通

3.1 主从环境准备与参数配置实战

先从搭建环境说起。我用两台MySQL实例来演示，实际生产环境一般会分开部署到不同的物理机或云主机上。假设主库IP是192.168.1.10，从库IP是192.168.1.11，MySQL版本统一用5.7。

主库配置，在my.cnf的[mysqld]部分添加：

ini复制server-id=1
log-bin=mysql-bin
binlog_format=ROW
binlog_row_image=FULL
expire_logs_days=14
# 把需要同步的库加进来，多个库重复写多行
binlog-do-db=order_db
# 忽略系统库
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
binlog-ignore-db=performance_schema
binlog-ignore-db=sys

从库配置：

ini复制server-id=2
relay-log=mysql-relay-bin
read_only=1
# log_slave_updates=1  # 如果从库下面还有从库，才需要开启

主库配置完成后，创建一个用于复制的专用账号：

sql复制CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'Repl_2024_Strong';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

然后查看主库当前的binlog文件名和偏移量，这个信息后面配置从库时要用到：

sql复制SHOW MASTER STATUS;

输出类似这样：

text复制+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000014 |      437 | order_db     | mysql            |                   |
+------------------+----------+--------------+------------------+-------------------+

接下来需要把主库的存量数据导入从库。如果是全新环境，直接从零开始复制就行，但实际业务一般都会涉及存量数据迁移，这里推荐用mysqldump导出主库数据，再导入从库，注意加--master-data=2参数，它会在导出文件中自动记录主库的binlog位置信息：

bash复制mysqldump -uroot -p --single-transaction --master-data=2 --databases order_db > order_db.sql
mysql -uroot -p < order_db.sql

从库数据导入完成后，在从库上执行：

sql复制CHANGE MASTER TO
  MASTER_HOST='192.168.1.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='Repl_2024_Strong',
  MASTER_LOG_FILE='mysql-bin.000014',
  MASTER_LOG_POS=437;

START SLAVE;

查看复制状态是否正常：

sql复制SHOW SLAVE STATUS\G

重点看这三项：

Slave_IO_Running: Yes——IO线程正常，正在从主库拉取binlog。
Slave_SQL_Running: Yes——SQL线程正常，正在执行中继日志。
Seconds_Behind_Master: 0——从库延迟为0。

如果IO线程是Connecting状态，最可能是主库账号权限不对或网络不通。如果SQL线程是No状态，多半是主从数据不一致导致的复制中断，排查起来比较麻烦，后面实战部分会细说。

3.2 应用层动态数据源路由的实现

环境搭好了，接下来重点是应用层的改造。我先说明一下，我这里的示例是基于Java技术栈，使用Spring Boot和MyBatis这套常见组合。不管你的团队用什么语言和框架，核心思路是通用的——按操作类型做数据源路由。

先定义枚举类，区分主从：

java复制public enum DataSourceType {
    MASTER, SLAVE
}

然后实现一个ThreadLocal工具类，用于保存当前线程应该使用哪个数据源：

java复制public class DynamicDataSourceContextHolder {
    private static final ThreadLocal<DataSourceType> CONTEXT = new ThreadLocal<>();

    public static void setDataSource(DataSourceType type) {
        CONTEXT.set(type);
    }

    public static DataSourceType getDataSource() {
        return CONTEXT.get() == null ? DataSourceType.MASTER : CONTEXT.get();
    }

    public static void clearDataSource() {
        CONTEXT.remove();
    }
}

接下来继承Spring的AbstractRoutingDataSource，它是这个方案的核心。这个类的determineCurrentLookupKey()方法决定了每次数据库操作时实际使用哪个数据源：

java复制public class DynamicDataSource extends AbstractRoutingDataSource {

    @Override
    protected Object determineCurrentLookupKey() {
        return DynamicDataSourceContextHolder.getDataSource();
    }
}

在Spring配置类中，把主从数据源都注册进去：

java复制@Configuration
public class DataSourceConfig {

    @Bean
    @ConfigurationProperties("spring.datasource.master")
    public DataSource masterDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    @ConfigurationProperties("spring.datasource.slave")
    public DataSource slaveDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    public DynamicDataSource routingDataSource(
            @Qualifier("masterDataSource") DataSource master,
            @Qualifier("slaveDataSource") DataSource slave) {
        Map<Object, Object> targetDataSources = new HashMap<>();
        targetDataSources.put(DataSourceType.MASTER, master);
        targetDataSources.put(DataSourceType.SLAVE, slave);

        DynamicDataSource routing = new DynamicDataSource();
        routing.setDefaultTargetDataSource(master);
        routing.setTargetDataSources(targetDataSources);
        return routing;
    }
}

这里有一个很容易被忽视的地方，就是setDefaultTargetDataSource(master)。默认数据源必须是主库，一旦路由逻辑出问题，或者某段代码没有走切面，宁可把请求打到主库，也不能打到从库。读操作打到主库顶多多一点压力，写操作打到从库直接报错，相比之下后果完全不同。

3.3 事务场景下的路由规避

有了动态数据源之后，还需要一个AOP切面来实现在方法级别自动切换数据源。我用自定义注解的方式，在需要走从库的查询方法上标注一下：

java复制@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface ReadOnly {
}

然后编写AOP切面：

java复制@Aspect
@Component
public class DataSourceAspect {

    @Around("@annotation(readOnly)")
    public Object switchDataSource(ProceedingJoinPoint joinPoint, ReadOnly readOnly) throws Throwable {
        try {
            DynamicDataSourceContextHolder.setDataSource(DataSourceType.SLAVE);
            return joinPoint.proceed();
        } finally {
            DynamicDataSourceContextHolder.clearDataSource();
        }
    }
}

在Service层的查询方法上加上@ReadOnly注解：

java复制@ReadOnly
public OrderInfo getOrderById(Long orderId) {
    return orderMapper.selectById(orderId);
}

这个方案看起来很简单，但有一个非常关键的坑：事务和路由的优先级问题。Spring的事务是在进入Service方法时开启的，如果某个Service方法加了@Transactional注解，事务管理器在事务开始时就会把数据库连接绑定到当前线程，而数据源的路由是在事务启动之前就已经通过AOP切面确定了的。如果这个顺序没处理好，就会出现"事务中先走了写库，然后切到读库，但事务连接还是绑定在主库上"这种混乱状态。

更直接地说，事务方法内的所有SQL，包括查询，都必须在主库上执行。拿订单系统的典型场景举例，下单这个操作必然是一个事务，里面包含了创建订单、扣库存、更新用户余额等一系列操作。如果这个事务方法里还包含了一些查询逻辑，比如查一下用户当前的优惠券，那这个查询也必须走主库。如果在事务方法上加了@ReadOnly注解，让查询走了从库，最终结果就是：你从从库查到的数据和主库可能不一致，更糟糕的是，从库是read_only的，如果事务中有任何写操作，SQL一定会报错。

所以，事务方法必须走主库，而我的做法是用一个独立的注解来标记，不允许和@ReadOnly混用。这里我建议你使用这样的方式：在切面中，如果检测到当前线程已经有事务上下文，就直接放行，不做路由切换：

java复制@Around("@annotation(readOnly)")
public Object switchDataSource(ProceedingJoinPoint joinPoint, ReadOnly readOnly) throws Throwable {
    // 如果当前已经处于事务中，不再切换数据源
    if (TransactionSynchronizationManager.isActualTransactionActive()) {
        return joinPoint.proceed();
    }
    try {
        DynamicDataSourceContextHolder.setDataSource(DataSourceType.SLAVE);
        return joinPoint.proceed();
    } finally {
        DynamicDataSourceContextHolder.clearDataSource();
    }
}

这样就最保险了，事务方法内部全部走主库，不会有脏读风险。

3.4 监控与验证：怎么确认读写真的分离了

代码改造完成，启动应用后，怎么验证读写分离真的生效了？我平时会用这么几种手段。

最直接的方式是登录主库和从库，分别看一下线程列表。在主库上执行SHOW PROCESSLIST;，如果看到连接的Command列大多数是Query，并且Info列有INSERT、UPDATE、DELETE语句，说明写流量是过来的。再从库上执行同样的命令，如果看到的Info列大多是SELECT语句，说明读流量已经被正确分过去了。

如果你做得更细致一些，可以在订单模块的某个查询方法里临时加一行日志，打印当前使用数据源的标识。我一般在DynamicDataSource的determineCurrentLookupKey()里做个简单的计数统计，把这个值和实际业务量做个对比，就能大致判断读写比例的分流情况。

另外，监控系统一定不能缺。对主从库的QPS、CPU使用率、连接数、主从延迟这些指标做周期性采集，形成一个可视化面板，这样读写分离之后，业务量如果出现变化，你能快速看到主从库的负载对比。一旦发现从库CPU居高不下，说明读流量比例很大，可能要考虑增加从库数量；如果从库CPU很低但延迟持续增长，就得看看是不是从库规格配低了。

4. 问题规避：这些坑我一个个踩过来

4.1 主从延迟：最经典也最难缠的问题

读写分离方案上线后，我遇到的最头疼的问题就是主从延迟。订单系统的业务场景是，用户下单这个动作写入主库后，紧接着页面会跳转，用户可能立刻就去查看"我的订单"列表。如果这个查询走了从库，而复制还没完成，用户就会看到"订单不存在"或者"订单状态不对"，这种体验是非常负面的，而且客诉量会直线上升。

我踩过的坑是这样的：上线初期，我对主从延迟的感知不强烈，认为MySQL在主从同一机房、网络延迟极低的情况下，延迟应该在毫秒级别。但实际运行后发现，高峰期主库写入压力大，加上从库本身可能还在承担大量读请求，复制延迟有时候会波动到几百毫秒甚至几秒。对一个订单系统来说，几百毫秒已经是完全无法接受的了。

要解决这个问题，我从几个层面做了处理。最核心的兜底策略是：对一致性要求极高的读操作，强制走主库。订单详情页、下单后的确认页、支付回调后的结果查询，这些必须走主库。只有那些允许短暂延迟的查询，比如历史订单列表、订单状态的可选分支展示，才允许走从库。

实现方式也很简单，我在@ReadOnly注解里加了一个value属性，用来区分不同等级的读操作：

java复制@Retention(RetentionPolicy.RUNTIME)
public @interface ReadOnly {
    // 是否允许读取可能延迟的数据，默认不允许
    boolean tolerateDelay() default false;
}

对于不能用延迟的查询，就不加@ReadOnly注解，让它走默认主库。

我还可以用另一个策略，就是"关键路径强制主库"方案。比如用户提交订单成功后，会在当前线程里设置一个标记，这个标记在短时间内让该用户的读请求都强制走主库，确保他后续的查询能看到自己刚刚下的单。这个方案适合C端用户场景，效果也不错，但实现起来会稍微复杂一点，需要处理标记的过期和清理。

当然，从根本上说，还是要尽可能减小主从延迟本身。比如把从库的innodb_flush_log_at_trx_commit设为2，降低同步刷盘的压力，业务高峰期延迟会明显下降。这类参数要结合自己对数据安全的要求来权衡。

注意：对订单系统而言，妥协一致性的方案一定要配合产品需求来定，而不是纯技术决策。到底哪些数据允许延迟可见，哪些不允许，一定要和业务产品同学对齐，技术方案再好，与业务预期不一致也是白搭。

4.2 主从切换时的血泪教训

这个教训我印象太深了。有一次主库所在的物理机出现了硬件告警，需要把流量切到从库。当时因为提前做了预案，切换过程本身还算顺利。但切换后，我们犯了一个非常低级的错误——没有及时修复旧主库的数据差异，而且旧主库的自动恢复机制把一些未同步的数据又写了回去，导致数据混乱。

主从切换场景下，如果业务对数据一致性要求非常高，最稳的方案是用半同步复制来保证主从切换后数据不会丢。MySQL的普通异步复制下，主库提交一个事务后，从库可能还没收到binlog，主库就直接挂了。这时候如果强行把从库提升为主库，最后几个事务的数据就无法挽回了。

半同步复制的原理是，主库在提交事务时，必须等待至少一个从库确认收到了这个事务的binlog，才会真正提交成功。简单说，它在可用性和一致性之间做了一个折中。开启半同步复制也比较简单，需要加载插件并设置相关参数，主从都要配置，这里给出一个最小配置示例：

主库：

ini复制plugin-load="rpl_semi_sync_master=semisync_master.so"
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000

从库：

ini复制plugin-load="rpl_semi_sync_slave=semisync_slave.so"
rpl_semi_sync_slave_enabled=1

rpl_semi_sync_master_timeout=1000表示如果从库确认超时达到1秒，主库会自动退化为异步复制，避免因为从库故障导致主库不可写。这个超时时间需要结合实际业务对响应时间的敏感度来调，我一般设500到1000毫秒之间。

关于主从切换，还有几个具体建议：

提前编写好切换脚本，并且要定期演练。不要等到故障发生了才翻文档，手忙脚乱操作数据库是很危险的。
切换前务必确认从库的数据追平了主库，也就是Seconds_Behind_Master必须为0，并且要等它稳定在0一段时间再切换，我一般会等个5分钟。
切换完成后，检查新主库的binlog是否开启、server-id是否正确、旧主库是否还能正常连入，这些都是很容易遗漏的细节。

4.3 数据一致性：那是"兜底"问题，不只是延迟问题

主从延迟只是从库数据暂时落后，但最终一致会追上。真正让人头疼的是因为复制链路中断、从库SQL执行报错等原因，导致从库数据与主库产生了永久性偏差。

订单系统里如果出现这种情况，后果非常严重：可能用户在列表页看到一个订单，点进去详情却是另一个订单，或者订单金额对不上。这类问题排查起来非常耗时，而且很难通过业务日志去发现，只能靠定期的数据核对。

我先说从库出现复制中断时最常见的排查方式。当SHOW SLAVE STATUS中的Slave_SQL_Running显示No时，代表SQL线程停掉了。通常是因为从库上执行某条SQL时发生错误，比如表结构不一致、主键冲突等。这时可以用：

sql复制SHOW SLAVE STATUS\G

查看Last_Errno和Last_Error两个字段，会看到具体的报错信息。大多数情况下，可以手动在从库上补一条相同的数据，或者删掉多余的数据，然后：

sql复制STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

跳过这条错误的SQL。但这只是权宜之计，想要保证长期的稳定性，必须搞清楚为什么会有这条错误SQL，是主从表结构不一致，还是有人手工改了从库数据。我在生产环境里见过从库数据被某个运维同学手工清洗后导致的复制中断，排查了很久才定位到。

为了避免这类问题，我强烈建议定期做数据一致性校验。MySQL本身没有内置的命令，我用过的比较靠谱的方案是借助工具去做数据比对。比较有名的方案是pt-table-checksum，它可以对比主从两端的数据，找出差异行。这个工具对线上业务会有一些影响，尽量在低峰期执行。一旦发现差异，再用pt-table-sync去修复。注意，pt-table-sync在修复数据前会先修改从库数据，这本身就有风险，一定要先备份。

读写分离上线后，把数据一致性巡检纳入固定运维计划。我建议至少每周跑一次全量比对，每天抽样比对，确保问题能被及时发现。

4.4 监控告警与日常维护的几条地盘经验

方案上线之后，真正考验人的是日常运维。我总结几条自己的地盘经验，每条都是踩过坑换来的。

第一，主从延迟告警不能只看绝对值，还要看趋势。监控告警规则如果设置的是"延迟超过10秒就报警"，那遇到秒级波动的场景，报警会非常频繁，容易让人麻木。我后来改成了"延迟在30秒内连续5个采集周期超过5秒"这种条件触发，告警噪音一下子下来了很多，而且真的出问题时也不会漏。

第二，应用层的连接池参数必须单独调。主库和从库的负载特征完全不同，从库的连接数消耗远大于主库，因为大量读请求会并发过来。我给主从数据源分别配置了连接池，主库的maximum-pool-size天然要小一些，因为写操作本身并发不高；从库则要放得大一些，以承载更高的读并发。如果主从共用一个连接池，在高峰期会出现主库连接被读请求占满，写请求被阻塞，那就完全违背了读写分离的初衷。

第三，所有从库的账号权限必须收敛。从库只保留DML和查询权限，不给DDL权限，更不能有super权限。这样即使有人误操作，也很难把从库数据搞乱。同时，主库账号控制和从库账号分开，不要让应用层用一个账号访问所有实例。

第四，关于binlog的保留时长。有从库的情况下，主库的binlog不能被随意清理。如果从库因为某些原因中断时间比较长，而主库的binlog已经过期被删除了，那么从库就无法继续追平，只能重新做全量同步。我的配置是expire_logs_days=14，配合每天备份全量数据，这样即使从库中断了超过14天，也能用备份重建，之后再做增量复制。

5. 关于这个方案的一些个人体会

读写分离这套方案，从架构上看不算复杂，真正复杂的是在实现过程中如何处理各种细节和边界情况。经过这次改造，我的一个核心体会是：先想清楚哪些读操作能容忍延迟，哪些绝对不能，比任何技术选型都更重要。这决定了你的路由策略、注解设计和兜底方案。

另外，也要对团队协作给予足够重视。当时做这个改造的时候，前后端同学对"为什么订单列表页偶尔会慢、下单后为什么偶尔看不到最新订单"这些现象是不理解的，后来我们专门做了一次内部技术分享，把读写分离的架构、延迟的应对策略、哪些场景会走主库哪些场景走从库讲清楚，大家的协作效率明显好多了。

如果你正准备在订单系统里做读写分离，我建议你从最小的范围开始，比如先只在一个查询量最大的接口上线切流，观测一段时间，确认没有数据一致性问题和性能问题后，再逐步铺开。不要想着一步到位全量灰度，尤其是涉及核心交易链路的系统，稳妥永远比速度重要。