目录业务整体场景场景 1计价规则高频读取规则可后台动态修改业务场景痛点 难点设计思路技术选型Canal Redis MySQL场景 2充电桩设备长连接上报 设备告警实时推送业务场景痛点 难点设计思路技术选型WebSocket RocketMQ场景 3充电主链路解耦充电完成后账单、通知、统计任务业务场景痛点 难点设计思路技术选型RocketMQ场景 4防止重复订单设备重复上报、网络重试产生脏数据业务场景痛点 难点设计思路技术选型MySQL 唯一索引 Redis场景 5大量异常订单设备断电、网络异常导致订单僵死业务场景痛点 难点设计思路技术选型XXL‑Job 分布式定时任务场景 6整体微服务架构多模块拆分、高可用保障业务场景痛点 难点设计思路技术选型Spring Cloud Alibaba Nginx整体技术栈选型总结面试口述版适配简历深挖、面试口述每一点业务场景 → 真实痛点难点 → 设计思路 → 技术选型 → 落地效果面试可以直接复述。业务整体场景智慧充电运营平台面向充电运营商管理充电桩场站、充电设备、C 端用户、充电订单、计价计费、营销活动充电桩硬件设备通过长连接实时上报充电数据、告警事件平台需要做计费算价、订单流转、异常订单兜底、运营可视化监控。 业务流量特征充电桩设备海量并发上报充电过程持续上报电压、电流计价规则会动态变更峰谷电价、服务费、优惠策略运营商后台随时修改充电订单状态流转复杂启动、充电中、暂停、结束、设备异常断电大量异常场景设备离线、网络闪断、上报乱序、中途断电高并发写订单创建、状态变更高频读计价规则查询每一次充电上报都要读取计价部分业务不能同步阻塞账单生成、消息通知、统计数据同步做会拖垮主链路。场景 1计价规则高频读取规则可后台动态修改业务场景每次设备上报充电数据都需要读取最新计价规则峰谷时段、服务费、折扣来实时计算充电费用运营商后台可以随时修改计价规则表 MySQL。每次充电上报都要拿计价规则QPS 很高。痛点 难点如果每次算价直接查 MySQL高频查询压垮 DB接口 RT 高原先平均 500ms如果单纯使用 Redis 缓存修改 MySQL 之后Redis 缓存更新不及时DB 和 Redis 数据不一致会出现计费错误产生客诉不允许缓存长时间旧数据业务要求规则修改后生效延迟尽可能小。设计思路不能依靠开发手动更新缓存容易漏写、代码埋点侵入业务。采用binlog 监听准实时同步MySQL 计价规则表发生 insert/update/delete自动触发同步逻辑刷新 Redis 缓存做到 DB 为源Redis 为副本。技术选型Canal Redis MySQLMySQL业务源库存储完整计价规则开启 binlog row 模式Canal监听 binlog捕获计价规则表变更事件Canal 客户端消费变更事件直接对 Redis 做更新 / 删除缓存延迟 1s业务代码全部读取 Redis 做计价不再大量查询 MySQL兜底设置 Redis 短期过期时间防止 Canal 故障导致永久脏缓存。效果查询 RT 从 500ms 降到 90msDB 压力大幅下降规则变更秒级生效。场景 2充电桩设备长连接上报 设备告警实时推送业务场景充电桩设备和后端建立长连接持续上报充电数据设备发生故障温度过高、过流平台需要实时把告警推送到运营商管理后台、手机端。痛点 难点设备分散服务多实例部署设备连接可能落在任意一个后端实例告警事件产生在 A 服务实例但用户 web / 手机连接在 B 实例原生 WebSocket 无法跨机器推送消息网络抖动、设备断连重连消息丢失、重复推送不能轮询数据库拉告警轮询延迟高、数据库压力大。设计思路设备与服务端建立 WebSocket 长连接维护会话映射设备 ID / 用户 ID → 当前连接在哪台服务实例产生告警事件发送消息到 MQ各个微服务消费 MQ判断告警接收方的会话是否在本实例本地如果存在执行推送增加告警持久化落库作为兜底客户端没收到可以拉取历史告警。技术选型WebSocket RocketMQWebSocket做客户端与服务端双向长连接RocketMQ实现跨实例消息广播解决分布式环境下 WebSocket 跨机器推送问题。场景 3充电主链路解耦充电完成后账单、通知、统计任务业务场景充电结束主链路需要完成订单状态更新同时要做账单生成、用户消息推送、运营统计数据更新。痛点 难点如果全部同步执行主链路响应慢一旦账单生成缓慢会阻塞订单状态返回下游业务短信、统计偶尔失败不能影响核心订单主流程充电结束并发量大同步处理会造成接口超时系统吞吐量上不去。设计思路核心流程只做订单状态落库其余非强依赖业务全部异步化消息驱动。 充电完成发送 RocketMQ 事件消息多个消费端分别消费生成账单、消息通知、统计指标。消息支持重试下游失败不影响主业务。技术选型RocketMQ支持重试机制、消息可靠Topic 拆分不同业务消费组互不干扰。效果系统整体吞吐量提升 3 倍。场景 4防止重复订单设备重复上报、网络重试产生脏数据业务场景充电桩设备网络不稳定会重复上报充电启动报文如果不做控制会生成多条重复充电订单造成计费错乱。痛点 难点设备侧不可信会重复上报分布式多实例请求单机锁无效不能靠业务代码判断高并发下判断之后写入会出现竞态条件。设计思路使用设备上报携带的唯一业务报文 ID作为幂等标识MySQL 数据库建立唯一索引数据库层面拦截重复插入前置增加 Redis 幂等校验做拦截减少 DB 报错数据库唯一索引作为最终兜底防线。技术选型MySQL 唯一索引 Redis效果杜绝重复订单订单数据准确率 100%。场景 5大量异常订单设备断电、网络异常导致订单僵死业务场景充电桩设备异常断电、网络断开设备不会上报结束报文数据库订单一直停留在「充电中」僵死状态不会闭环结算。靠人工排查成本极高。痛点 难点设备失联不会主动通知后端订单数量大人工排查处理成本高不能简单写死超时充电时长有长有短要结合业务规则判断异常。设计思路分布式定时任务周期扫描订单表按照业务规则识别僵死 / 异常订单自动执行订单关闭、费用结算完成闭环。 需要解决集群多实例部署定时任务不能多机器同时执行避免重复处理同一批订单。技术选型XXL‑Job 分布式定时任务分布式锁保证任务只执行一次自动扫描、自动闭环异常订单。效果人工处理成本降低 90%。场景 6整体微服务架构多模块拆分、高可用保障业务场景整个系统包含设备服务、订单计价服务、场站管理、运营后台、告警服务流量入口来自设备上报、运营后台接口、C 端 H5。痛点 难点业务模块耦合在一起迭代发布互相影响部分服务故障不能拖垮整个平台需要统一的服务注册发现、配置管理、熔断降级前端、设备请求流量入口需要负载均衡。设计思路业务按领域拆分微服务订单计价服务、设备服务、场站运营服务服务注册发现统一配置中心接口熔断降级防止雪崩Nginx 做反向代理负载均衡。技术选型Spring Cloud Alibaba NginxNacos注册中心 配置中心Sentinel熔断、限流、降级OpenFeign远程调用Nginx请求负载均衡。整体技术栈选型总结面试口述版Spring Cloud Alibaba微服务底座Nacos 注册配置Sentinel 熔断OpenFeign 远程调用解决模块化拆分、高可用MySQL核心业务源数据库订单、场站、计价规则唯一索引做幂等兜底Redis缓存计价规则、幂等令牌配合 Canal 实现准实时缓存更新RocketMQ异步解耦账单、通知分布式 WebSocket 告警跨实例推送消息重试保障下游可靠性Canal监听 MySQL binlog计价规则变更准实时同步 Redis解决 DB‑Redis 一致性WebSocket接收设备上报、实时推送告警消息XXL‑Job分布式定时任务自动处理僵死异常订单Nginx反向代理、负载均衡。