设计一个支持百万级用户访问的半导体芯片销售平台（类似英飞源的销售系统），请说明其架构设计，包括负载均衡、缓存、数据库分片等，并解释如何保证数据一致性和系统容灾。
答案
1) 【一句话结论】采用微服务+分布式架构，通过负载均衡分散请求、多级缓存降低数据库压力、数据库分库分表提升读写能力、主从复制+读写分离保证数据一致性与性能，结合异地多活实现容灾，整体支撑百万级并发。
2) 【原理/概念讲解】
首先讲负载均衡：负载均衡是请求分发的关键，比如Nginx作为四层负载均衡器，通过轮询、加权轮询等算法将用户请求分发到后端服务器集群，确保请求均匀分布，避免单点过载。类比“交通枢纽”——把大量用户请求像汽车一样分发到不同车道（后端服务器），避免某条车道拥堵。健康检查机制（如HTTP GET /healthcheck接口）确保只分发到健康的服务器，权重高的服务器分发更多请求。
接着讲缓存：缓存用于减少数据库访问，提升响应速度。本地缓存（如Guava Cache）存储单机热点数据（如热门芯片规格、用户登录状态），响应快但内存有限；分布式缓存（如Redis集群）存储多机共享的热点数据（如热门芯片价格、用户收藏列表），支持持久化，但需网络通信。缓存雪崩的解决：设置缓存过期时间（如随机化过期时间，避免同一时间大量缓存失效），或使用分布式锁保证缓存更新时不会雪崩（如Redis的SETNX命令）。
再讲数据库分片：分片是将大表拆分成小表，分散数据库压力。垂直分片是按业务拆库（如销售库、库存库、用户库），每个库负责特定业务，减少跨库查询；水平分片是按数据量拆表（如按用户ID哈希分表、按时间分表），将大表拆成多个小表，分散读写压力。跨分片聚合查询的解决方案：使用分片路由器（如ShardingSphere）统一管理分片，将聚合请求路由到对应分片；或使用全局ID（如雪花算法生成唯一ID）保证数据唯一性，聚合时通过全局ID关联分片数据；或在上层服务（如聚合服务）中处理聚合逻辑，避免跨分片查询。
最后讲数据一致性与容灾：数据一致性采用“最终一致性”，通过消息队列（如Kafka）异步同步数据，结合补偿机制（如重试、回滚）保证一致性。例如，订单创建后发送消息到库存系统，库存系统处理后再确认，若库存系统延迟，订单服务重试或回滚。容灾采用“异地多活”，主数据中心和灾备中心部署相同架构，通过异步数据同步（如MySQL GTID复制）保证数据一致性，网络故障时自动切换到灾备中心，延迟控制在秒级（如通过消息队列异步同步，避免实时同步影响性能）。
3) 【对比与适用场景】
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡 | 请求分发机制 | Nginx（四层，HTTP/HTTPS，配置灵活）；LVS（七层，支持集群，算法多） | 前端请求分发，微服务入口 | 需健康检查，避免挂服务器被分发 |
| 缓存 | 数据存储优化 | 本地缓存（Guava，JVM内存，响应快）；分布式缓存（Redis，集群，持久化） | 热点数据缓存，多机环境 | 本地缓存内存有限，分布式缓存需网络通信 |
| 数据库分片 | 数据库拆分 | 垂直分片（按业务拆库，如销售/库存库）；水平分片（按数据量拆表，如按ID哈希分表） | 大规模数据读写，高并发场景 | 分片策略需考虑热点表（如最近7天订单） |
| 数据一致性 | 数据一致性保障 | 最终一致性（异步同步+补偿）；强一致性（2PC，适合小数据） | 大规模并发，对一致性要求高的场景 | 强一致性性能低，适合小数据量 |
4) 【示例】
- 分片路由器配置（ShardingSphere）：
# 分片规则配置 shardingRule: mydb: tables: sales_order: actualDataNodes: db0.sales_order_0, db1.sales_order_1, db2.sales_order_2 shardingKey: user_id algorithmClass: org.apache.shardingsphere.core.rules.sharding.standard.HashShardingAlgorithm order_item: actualDataNodes: db0.order_item_0, db1.order_item_1, db2.order_item_2 shardingKey: order_id algorithmClass: org.apache.shardingsphere.core.rules.sharding.standard.HashShardingAlgorithm - 缓存雪崩Redis配置（随机过期时间）：
# 设置缓存过期时间（随机范围：5-10秒） SET key value EX 7
5) 【面试口播版答案】
“面试官您好，针对百万级用户访问的半导体芯片销售平台，我设计的架构核心是采用微服务+分布式架构，通过负载均衡分散请求、多级缓存降低数据库压力、数据库分库分表提升读写能力、主从复制+读写分离保证数据一致性与性能，结合异地多活实现容灾。具体来说，前端通过Nginx做四层负载均衡，分发请求到后端微服务集群；缓存层面，使用Redis集群作为分布式缓存，同时每个微服务启动本地Guava Cache缓存热点数据，减少数据库访问；数据库方面，采用垂直分库（销售、库存、用户库）和水平分片（按用户ID哈希分表），并配置主从复制+读写分离，主库写，从库读，提升读性能；数据一致性方面，采用最终一致性，通过消息队列（如Kafka）和补偿机制保证，比如订单创建后发送消息到库存系统，库存系统处理后再确认；容灾方面，采用异地多活，主数据中心和灾备中心部署相同架构，通过数据同步（如MySQL GTID复制）保证数据一致性，网络故障时自动切换到灾备中心。”
6) 【追问清单】
- 跨分片聚合查询如何解决？
- 回答要点：使用分片路由器（如ShardingSphere）统一管理分片，将聚合请求路由到对应分片；或使用全局ID（如雪花算法）保证数据唯一性，聚合时通过全局ID关联分片数据。
- 缓存雪崩如何具体实现？
- 回答要点：设置缓存过期时间（如随机化过期时间），或使用分布式锁（如Redis SETNX）保证缓存更新时不会雪崩。
- 异地多活数据同步的延迟如何控制？
- 回答要点：使用异步同步（如消息队列），或设置同步延迟阈值（如1-2秒），避免实时同步影响性能。
- 微服务间通信如何保证高可用？
- 回答要点：使用服务注册与发现（如Nacos），结合熔断、限流、降级（Hystrix/Resilience4j）保证服务间通信的稳定性。
- 数据库分片后，热点表（如最近7天订单）如何处理？
- 回答要点：对热点表单独分片（如按时间分表），或使用读写分离+缓存（如从库读热点表数据，缓存到Redis）。
7) 【常见坑/雷区】
- 跨分片聚合查询未解决，导致统计类接口性能低或数据不一致。
- 缓存雪崩未处理，导致大量请求直接访问数据库，引发雪崩。
- 异地多活同步延迟未控制，实时同步导致网络延迟高，影响用户体验。
- 数据库分片策略不合理，如按时间分表但未考虑热点表，导致该表成为瓶颈。
- 数据一致性过度追求强一致性（如2PC），导致性能下降，适合小数据量场景。