上交所的交易系统通常采用微服务架构，请设计一个核心交易服务（如订单处理服务）的架构，并说明如何处理每秒万级订单的高并发请求。
上海证券交易所A06难度：困难
答案
1) 【一句话结论】核心交易服务采用微服务架构，通过负载均衡、消息队列异步解耦、多级缓存加速、限流熔断防雪崩，结合数据库分库分表，有效应对万级订单高并发。
2) 【原理/概念讲解】老师口吻，解释关键技术：
- 微服务：将系统拆分为独立服务（如订单服务仅处理订单创建/修改/查询），每个服务职责单一，便于独立部署和扩展。
- 负载均衡：如Nginx将请求分发到多个订单服务实例，避免单点过载。
- 消息队列：如Kafka，订单创建后先写入队列，由消费者异步处理，解耦请求与响应，提升吞吐量（类比：餐厅点餐后先放传菜口，厨房再处理，避免点餐员等待）。
- 多级缓存：如Redis缓存订单状态、用户订单列表，减少数据库压力（类比：超市货架，常用商品放在货架前，减少去仓库拿货时间）。
- 限流熔断：如Sentinel对高频请求限流（如QPS>1000时返回429），熔断服务防雪崩（类比：交通红绿灯，高峰期限流，避免拥堵）。
- 数据库分库分表：订单表按时间/订单号分库分表，水平扩展数据库，提高读写性能。
3) 【对比与适用场景】（负载均衡算法对比）
| 算法 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 轮询 | 按顺序分发请求 | 简单公平 | 请求无权重，实例负载均衡 | 新实例冷启动可能不均 |
| 随机 | 随机选择实例 | 负载可能不均 | 实例数量少，负载轻 | 需考虑负载不均 |
| 加权轮询 | 按权重分发 | 考虑实例性能 | 实例性能差异大 | 权重计算复杂 |
| 源地址哈希 | 根据客户端IP哈希 | 长期固定实例 | 客户端IP稳定 | 客户端迁移导致请求跳转 |
4) 【示例】订单处理服务架构（伪代码）：
客户端请求（如POST /orders）：
{ "userId": 123, "productId": 456, "quantity": 2 }
订单服务处理流程：
- 负载均衡分发请求到实例；
- 验证用户（Redis缓存用户信息，若不存在查数据库）；
- 检查库存（调用库存服务，或消息队列异步检查）；
- 生成订单ID（UUID），执行数据库事务：
INSERT INTO orders (id, user_id, product_id, quantity, status) VALUES (..., ...)；UPDATE user_orders SET order_count = order_count + 1 WHERE user_id = ...；
- 更新Redis缓存：
SET order:1234567890:status=created；SET user:123:orders:1234567890；
- 写入Kafka（主题：
order-created，payload：订单信息）； - 返回响应：
201 Created，订单ID。
5) 【面试口播版答案】
面试官您好，针对上交所交易系统订单处理服务的高并发设计，核心思路是采用微服务架构结合分布式技术，具体来说：
首先，通过负载均衡（如Nginx）将请求分发到多个订单服务实例，实现水平扩展。然后，订单创建后先写入消息队列（如Kafka），由消费者异步处理，解耦请求和响应，提升吞吐量。同时，使用Redis作为多级缓存，缓存订单状态和用户订单列表，减少数据库压力。为了防雪崩，引入限流熔断（Sentinel），对高频请求限流，当请求超过阈值时熔断服务。数据库层面，订单表按时间分库分表，水平扩展。这样，订单服务能高效处理万级订单，保证低延迟和高可用。
6) 【追问清单】
- 问题1：如何处理分布式事务？
回答要点：采用Saga模式或两阶段提交（2PC），结合消息队列补偿，确保订单与库存的最终一致性。 - 问题2：消息队列的可靠性如何保障？
回答要点：消息持久化（Kafka日志存储）、重试机制（消费失败后重试）、死信队列（处理无法重试的消息）。 - 问题3：缓存与数据库的一致性如何解决？
回答要点：数据库写后异步更新缓存（或乐观锁），设置合理过期时间，避免脏读。 - 问题4：系统如何容灾？
回答要点：多活部署（主备切换）、数据备份（数据库/消息队列备份）、异常时自动告警切换。 - 问题5：如何优化订单查询性能？
回答要点：索引优化（订单ID/用户ID/状态）、分页查询（避免全表扫描）、Redis缓存查询结果。
7) 【常见坑/雷区】
- 坑1：直接同步写入数据库导致性能瓶颈，忽略异步处理，请求积压。
- 坑2：缓存未加过期/淘汰策略，引发缓存穿透/雪崩。
- 坑3：限流策略仅限接口，未考虑内部服务（如库存）限流，内部服务过载。
- 坑4：分布式事务处理不当，本地事务导致库存与订单不一致。
- 坑5：消息队列延迟过高，影响订单处理时效。