Bias implementation toward pri…

# 订单接口超时问题：坏味道分析与重构方案

一、典型坏味道排查清单

1. 数据库层坏味道

• N+1 查询问题：循环中逐条查订单详情、用户信息，2万日活高峰期连接池极易耗尽
• 缺少合理索引：订单表按 user_id + created_at 的组合查询若无复合索引，会全表扫描
• 大事务：下单接口在同一事务里扣库存、写订单、记日志、发通知，锁持有时间过长
• 深分页：LIMIT 100000, 20 这类写法导致扫描量巨大

2. 代码结构坏味道

• 上帝方法：一个 createOrder 方法几百行，混杂参数校验、库存计算、优惠分摊、支付对接
• 同步串行调用：物流、短信、积分等非核心逻辑全部同步执行，拉长响应时间
• 重复代码：订单/退款/售后各自实现一套状态判断，规则漂移难维护

二、重构方案（可长期维护）

1. 性能急救（1-2周）

• 开启 SQL 慢查询日志，用 EXPLAIN 定位慢 SQL，补齐索引
• N+1 改为批量查询（IN + 内存组装）或 JOIN
• 深分页改游标分页（WHERE id > lastId LIMIT n）
• 数据库连接池参数复核（HikariCP 的 maxPoolSize 与慢SQL数量匹配）

2. 架构解耦（1-2个月）

• 读写分离：报表类查询走从库，避免抢占交易连接
• 异步化削峰：非核心链路（通知、积分、日志）改为 MQ 异步，下单接口只保留“扣库存+建订单+支付预校验”
• 热点数据缓存：商品详情、库存预扣用 Redis，注意用 Lua 保证库存扣减原子性
• 大事务拆分：本地事务只管核心链路，扩展逻辑走“事务消息 + 最终一致性 + 对账补偿”

3. 代码可维护性改造（持续）

• 引入分层防腐：Controller → Service（编排） → Domain（业务规则） → Repository（数据访问）
• 订单状态机统一抽象（可用枚举 + 状态转移表），消除散落的 if-else
• 补充接口压测基线与关键路径单测，重构前先建防护网

三、落地节奏建议

1. 先观测后动手：接入链路追踪（如 SkyWalking）确认瓶颈在 DB、外部调用还是锁竞争，避免盲目重构

2. 小步快跑：按“加索引 → 拆异步 → 拆服务”顺序渐进，每步回归验证

3. 防复发：建立慢SQL审查、Code Review 检查项和容量预警

如能提供慢SQL日志或接口耗时分布，可进一步给出针对性方案。