假设用户量增长到百万级，充电预约系统的并发请求达到每秒数百次，请设计系统扩展方案，包括架构调整、缓存策略、负载均衡等。
长安汽车场景策划难度：困难
答案
1) 【一句话结论】
针对百万级用户、数百次/秒并发请求，充电预约系统需通过微服务拆分、分布式缓存（布隆过滤器防穿透+缓存+数据库）、异步消息队列+限流、数据库分库分表实现水平扩展，核心是“分而治之”，用缓存、异步、限流缓解实时压力，用分库分表支撑数据量。
2) 【原理/概念讲解】
老师口吻：高并发下的系统扩展核心是水平扩展（增加实例数量，像班级里多安排几个老师，每个老师负责一部分学生，总人数多了也不忙）。
- 限流：给系统“限水龙头”，不能一下子开太大（比如每秒只允许1000次请求，超过就返回429错误，防止服务因过载崩溃）。
- 缓存穿透：缓存里没数据，每次都去数据库查，导致数据库被“穿透”（比如查询不存在的充电桩ID，缓存全为空，每次都查数据库，数据库压力爆炸）。
- 缓存雪崩：多缓存同时过期（比如Redis集群中多个key同时到过期时间），导致大量请求直接打到数据库，数据库瞬间压力激增。
- 幂等性：同一请求重复执行结果不变（比如重复创建充电预约订单，不会生成两条订单，避免数据不一致）。
3) 【对比与适用场景】
以**布隆过滤器 vs 普通缓存（Redis）**为例：
| 对比项 | 布隆过滤器 | 普通缓存（如Redis） |
|---|---|---|
| 定义 | 空间高效的哈希集合 | 内存缓存，存储键值对 |
| 特性 | 只能判断“可能存在”或“一定不存在” | 存储真实数据，可精确查询 |
| 使用场景 | 防缓存穿透（判断是否命中缓存） | 存储真实数据（如充电桩状态） |
| 注意点 | 可能存在误判（比如判断“存在”但实际不存在） | 需要设置过期时间，防雪崩 |
4) 【示例】
- 布隆过滤器防缓存穿透实现：
假设查询充电桩ID（key="充电桩:123"）时，先走布隆过滤器：- 根据key计算3个hash值（如MurmurHash3），取模得到桶位（桶1、桶2、桶3）；
- 检查桶位是否全为1（代表可能命中），若全为1则可能命中，否则未命中（直接查数据库）；
- 若命中，再查Redis缓存，若Redis有数据则返回，否则查数据库并更新缓存。
- 订单创建幂等性实现（伪代码）：
def create_order(user_id, charger_id): order_id = generate_unique_id() # 生成唯一订单号 # 尝试获取分布式锁（如Redis锁） with redis_lock(f"order:{order_id}"): # 检查订单是否已存在（用订单号查询数据库） if not db.exists(f"order:{order_id}"): # 创建订单 db.set(f"order:{order_id}", {"user_id": user_id, "charger_id": charger_id}) return "订单创建成功" else: return "订单已存在，无需重复创建" - 令牌桶限流参数设置：
令牌桶容量=QPS*安全系数（假设QPS=1000，安全系数1.5，则容量=1500）；
填充速率=QPS/安全系数（约667个/秒）；
请求到达时，检查令牌桶是否有足够令牌，不足则拒绝请求（返回429错误）。
5) 【面试口播版答案】（约90秒）
“面试官您好，针对百万级用户、数百次/秒并发，我设计的扩展方案核心是‘分而治之’，通过微服务拆分、分布式缓存（布隆过滤器防穿透+缓存+数据库）、异步消息队列+限流、数据库分库分表实现水平扩展。首先，架构上拆分为用户、充电桩、订单等微服务，用Nginx负载均衡分发请求。缓存方面，先走布隆过滤器判断key是否存在（防穿透），若未命中再查Redis缓存，若Redis未命中才查数据库。限流用令牌桶，比如每秒1000个令牌，超过则返回429。订单创建时用唯一订单号或分布式锁保证幂等，避免重复下单。异步处理预约请求，放入Kafka，消费者慢慢处理，减少实时压力。数据库按区域分库分表，提升读写性能。这样系统就能支撑百万级并发了。”
6) 【追问清单】
- 问题1：如何保证订单创建的幂等性？
回答要点：用唯一订单号（如UUID）或分布式锁（如Redis锁），确保同一请求重复执行结果不变，避免重复创建订单。 - 问题2：缓存雪崩如何应对？
回答要点：给缓存设置随机过期时间（如5-10秒随机），或用分布式锁控制并发写入（多实例同时写入时，只有一个能成功，其他等待）。 - 问题3：布隆过滤器误判率如何优化？
回答要点：根据数据量调整hash函数数量（如数据量100万用7个hash函数）和位数（位数=数据量ln21.3），误判率可控制在1%以内。 - 问题4：限流参数如何设置？
回答要点：令牌桶容量=QPS*安全系数（结合系统CPU/内存资源），填充速率=QPS/安全系数，比如QPS=1000，安全系数1.5，则容量1500，填充速率667个/秒。 - 问题5：微服务间通信用什么协议？
回答要点：用gRPC（比RESTful更快，适合高并发），结合Nacos服务注册与发现，确保服务间动态调用。
7) 【常见坑/雷区】
- 坑1：未处理缓存穿透，导致数据库压力激增。
- 坑2：限流策略未设置，导致服务因过载崩溃。
- 坑3：缓存雪崩未应对，导致缓存全空时系统瘫痪。
- 坑4：幂等性未实现，导致重复创建订单（如充电预约）。
- 坑5：布隆过滤器误判率过高，影响缓存命中率。