大促期间，贸易系统面临高并发订单处理。请设计一个高可用架构，确保系统在流量峰值时仍能稳定运行，并说明关键组件和容灾方案。
南光（集团）有限公司财务法律类难度：中等
答案
1) 【一句话结论】
采用微服务+分布式架构，通过负载均衡分散流量、缓存提升读取性能、消息队列解耦异步任务、数据库分库分表防瓶颈，结合主备/多活容灾方案，确保高并发下系统稳定运行。
2) 【原理/概念讲解】
高可用架构需解决流量分散、请求加速、异步解耦、数据库防瓶颈及容灾。
- 负载均衡（如Nginx、LVS）：像“交通枢纽”，将用户请求分发到多台应用服务器，避免单点过载。
- 缓存（Redis）：像“临时仓库”，缓存热点数据（如商品信息、订单状态），减少数据库读取压力。
- 消息队列（Kafka）：像“快递中转站”，解耦订单处理与库存等异步任务，避免阻塞主流程。
- 数据库分库分表（如ShardingSphere）：像“拆大仓库为小仓库”，分散读写压力，防数据库瓶颈。
- 集群部署：应用、数据库等组件多台机器协同，提升处理能力。
- 容灾方案（主备/多活）：像“备用系统”，故障时快速切换，确保业务不中断。
3) 【对比与适用场景】
以负载均衡方案为例（表格）：
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Nginx | 反向代理+负载均衡 | 高性能，支持轮询、权重等算法，易配置 | Web应用前端，高并发访问 | 需配置健康检查，避免故障节点 |
| LVS | 专有负载均衡（Linux虚拟服务器） | 透明负载，支持IP负载均衡（LVS-NAT/LVS-DR），性能高 | 大规模集群，对性能要求高的场景 | 配置复杂，需内核支持 |
4) 【示例】
架构流程：用户下单请求→Nginx负载均衡分发到应用集群（3台Tomcat）→应用检查Redis缓存（订单状态、商品库存），若命中直接返回；若未命中，查询数据库（分库分表，如订单库按用户ID哈希分库，库存库按商品ID分库），更新Redis并推送Kafka消息队列（通知库存系统）。数据库主库实时同步备库，应用集群多机房部署（故障时通过DNS切换）。
伪代码（请求处理）：
def place_order(user_id, product_id, quantity):
# 1. 负载均衡分发
# 2. 检查缓存
order_cache = redis.get(f"order:{user_id}:{product_id}")
if order_cache:
return parse_cache(order_cache)
# 3. 查询数据库（分库分表）
order_db = sharding_db.query_order(user_id, product_id)
# 4. 更新缓存
redis.set(f"order:{user_id}:{product_id}", order_db, ex=3600)
# 5. 消息队列异步通知
kafka_producer.send("inventory_update", {"order_id": order_db.id, "product_id": product_id, "quantity": quantity})
return order_db
5) 【面试口播版答案】
面试官您好，针对大促高并发订单处理，我设计的系统高可用架构核心是“分布式+微服务”，通过多组件协同确保稳定。首先，负载均衡层用Nginx分发流量到应用集群（至少3台服务器），避免单点故障；应用层缓存Redis缓存热点数据（如商品信息、订单状态），减少数据库压力；订单处理采用消息队列（Kafka）异步化，解耦订单生成与库存扣减，避免阻塞；数据库通过分库分表（如订单库按用户ID哈希分库，库存库按商品ID分库）分散读写，防瓶颈；容灾方面，主数据库实时同步备库，关键节点（如应用、数据库）多机房部署，故障时通过DNS切换或主备切换快速恢复。这样，流量峰值时系统能稳定处理订单，同时容灾方案确保故障时业务不中断。
6) 【追问清单】
- 问：负载均衡具体选Nginx还是LVS？为什么？
回答要点：Nginx配置灵活，支持多种负载算法且易扩展，适合业务场景；LVS性能更高，适合超大规模集群，但配置复杂。 - 问：缓存如何处理雪崩或击穿？比如商品秒杀时？
回答要点：雪崩用随机过期时间，击穿用互斥锁（如Redis锁）或预加载热点数据。 - 问：消息队列如何保证订单处理的顺序性？比如库存扣减和订单状态更新？
回答要点：消息队列按顺序发送，应用端消费时保证顺序（如Kafka分区顺序消费），或用事务消息确保最终一致性。 - 问：数据库分库分表的具体策略？比如订单表如何分库？
回答要点：按用户ID哈希分库，按时间分表（如按月分表），结合读写分离（主从）提升性能。 - 问：容灾切换的RTO（恢复时间）和RPO（恢复点）目标？
回答要点：RTO控制在分钟级（如30秒内），RPO控制在秒级（如1秒内），通过主备切换或多活部署实现。
7) 【常见坑/雷区】
- 只说“高可用”而不提具体组件（如负载均衡、缓存），显得不具体。
- 忽略缓存问题（如雪崩、击穿），或消息队列积压，导致架构健壮性被质疑。
- 数据库设计单一（如只说分库分表，没提读写分离、索引优化）。
- 容灾方案不具体（如只说主备，没提切换机制或多活同步策略）。
- 架构过于复杂（如引入过多组件导致维护成本高，或没结合实际业务场景）。