一、背景：为什么订单系统需要读写分离？
1.1 缓存的局限性
在电商系统中，Redis常作为MySQL的前置缓存，能有效拦截大量查询请求。然而，这种方案对商品系统、搜索系统等用户无关型系统效果显著，因为所有用户看到的内容相同，缓存命中率极高。
但对于订单系统、账户系统、购物车系统等用户相关型系统，每个用户查看的数据都是个性化的（如“我的订单”），缓存命中率低，大量查询请求直接穿透到MySQL，导致数据库压力剧增。
1.2 读写比例失衡
互联网系统的读写比例通常严重失衡，约为9:1 到几十:1，即绝大多数请求为只读查询。因此，将读请求分散到多个实例，写请求集中在主库，是提升并发能力的有效手段。
二、读写分离方案设计与实现
2.1 基本概念
读写分离通过多个MySQL实例分担请求：
主库（Master）：处理所有写操作（INSERT、UPDATE、DELETE）
从库（Slave）：处理读操作（SELECT），数据通过主从同步保持一致性
2.2 数据同步原理
MySQL通过Binlog实现主从同步：
主库开启Binlog，记录所有数据变更
从库通过RelayLog跟踪主库Binlog变化
从库重放RelayLog中的操作，实现数据同步
2.3 应用层实现
在应用层，只需将读写请求路由到不同实例，通常无需修改业务逻辑。常见的实现方式包括：
手动修改DAO层：根据SQL类型选择数据源
使用中间件：如ShardingSphere、MyCAT等，自动路由
2.4 电商项目实战：ShardingSphere
在电商项目中，我们采用ShardingSphere实现读写分离。配置示例如下：
yaml
spring: shardingsphere: datasource: master: type: com.alibaba.druid.pool.DruidDataSource url: jdbc:mysql://master-host:3306/order_db slave1: type: com.alibaba.druid.pool.DruidDataSource url: jdbc:mysql://slave1-host:3306/order_db slave2: type: com.alibaba.druid.pool.DruidDataSource url: jdbc:mysql://slave2-host:3306/order_db rules: readwrite-splitting: data-sources: order-ds: write-data-source-name: master read-data-source-names: slave1,slave2
通过读写分离，数据库并发能力可提升几倍到十几倍，是用户量增长时的首选扩容方案。
三、读写分离的数据不一致问题与规避
3.1 问题根源：主从延迟
主从同步是异步的，存在微小延迟（通常几毫秒）。在这段时间内，主库已更新数据，但从库仍为旧数据，导致查询结果不一致。
3.2 典型场景：支付后订单状态不同步
用户支付完成后，主库订单状态更新为“已支付”，但立即跳转至订单页查询时，若请求路由到从库，可能仍显示“未支付”。
3.3 解决方案：业务逻辑规避
方案一：支付成功页跳转
支付完成后不直接返回订单页，而是跳转至支付成功页，提示用户支付成功。用户手动点击“查看订单”时，主从同步通常已完成，避免延迟问题。
方案二：强制读主库
将更新与查询放在同一事务中，事务内的查询会自动路由到主库。或对实时性要求高的查询显式指定读主库。
java
@Transactional public void payOrder(Long orderId) { // 更新订单状态 orderMapper.updateStatus(orderId, "PAID"); // 查询订单（同一事务内，读主库） Order order = orderMapper.selectById(orderId); }方案三：延迟重试
对于时效性不强的查询，可稍作延迟后重试，或提示用户“数据同步中”。
四、总结与最佳实践
读写分离是提升读并发能力的有效手段，尤其适用于读多写少的系统。
主从延迟不可避免，需通过业务设计规避，而非强求技术解决。
ShardingSphere等中间件可大幅降低实现成本，建议在生产环境使用。
监控主从延迟，设置告警阈值，及时处理同步异常。
读写分离不是银弹，当数据量或写并发极大时，仍需结合分库分表。
