阿里云 RDS MySQL 读写分离实践：千里达票务系统订单数据层高并发方案
景区购票高峰期间，千里达票务系统的数据库层承受着"读多写少"的典型压力：订单查询、余票查询、订单列表刷新等读操作占总请求的 80% 以上，而写操作（下单、扣库存）虽然量级较小，却对一致性要求极高。本文分享基于阿里云 RDS MySQL 读写分离的实践方案。
一、业务场景与问题
- 读放大：游客反复刷新购票页、查看订单，单次下单可能产生 10+ 次读请求；
- 写延迟敏感：下单、退款等写事务要求低延迟，主库负载过高会直接拖慢下单链路；
- 报表查询拖垮在线业务：运营侧的日报统计、渠道对账等复杂查询，曾直接把主库 CPU 打满。
二、方案设计：主实例 + 只读实例 + 代理
采用阿里云 RDS 的读写分离能力：
| 组件 | 作用 |
|---|---|
| RDS 主实例 | 承担所有写事务，保证数据一致性 |
| 只读实例 × 2 | 分担读流量，按需弹性扩容 |
| 数据库代理（RLS） | 自动路由读写请求，业务侧零改造 |
路由规则：SELECT 自动转发到只读实例，INSERT/UPDATE/DELETE 固定走主库；事务内查询也强制走主库，避免读到主从不一致的数据。
三、关键实现
3.1 连接配置（Spring Boot 示例）
spring:
datasource:
url: jdbc:mysql://rds-proxy.mysql.rds.aliyuncs.com:3306/ticket
# 通过代理连接，读写自动分流
3.2 强制主库读（避免延迟问题）
@Transactional(readOnly = false)
public Order createOrder(OrderReq req) {
// 事务内查询强制走主库，保证读到刚写入的订单
Order order = orderMapper.selectById(req.getOrderId());
}
3.3 慢查询治理
开启慢日志，定期分析 long_query_time > 1s 的 SQL，把报表类复杂查询全部迁移到只读实例或数仓。
四、踩坑复盘
- 主从延迟导致"下单后看不到订单"：刚提交的订单查不到，游客反复点提交。解决：订单详情接口强制走主库 + 前端增加提交成功态；
- 大事务阻塞：一次批量退票事务执行 10 秒，导致主库复制延迟飙升。解决：拆分小事务 + 限制单批退票数量；
- 连接池耗尽：只读实例连接数被打满，出现连接超时。解决：调大连接池、为报表查询单独建连接池并限制并发；
- 只读实例规格误配：只读实例与主实例规格相差过大，流量切过去后反而变慢。解决：按峰值读流量 1:1 规划规格。
五、效果与总结
读写分离上线后，主库 CPU 使用率从 90% 峰值降到 40% 以下，下单 P99 延迟稳定在 150ms 内。对千里达票务系统这类"读多写少、强一致"的业务，RDS 读写分离是成本最低、见效最快的扩容手段；后续流量继续增长，可按景区维度拆库或引入 PolarDB 分布式能力。
