一键三连，让算法推荐更多类似干货 ~
你最近面试被问到的最难的题是什么？ 评论区交流，我来解答
突然发现自己欠了一屁股 技术债 ？ 别薅头发了 —— 关注本专栏，带你清债～
零、设计一个xx系统的思路：
（1）业务拆解：明确核心功能（如券模板管理、库存控制）；
（2）技术选型：根据业务场景选择存储（MySQL/Redis）、中间件（MQ/RPC 框架）等；
（3）高并发处理：通过缓存（多级缓存）、异步（MQ 削峰）、存储优化（读写分离、分库分表）扛住流量；
（4）高可用保障：限流（控制流量峰值）、熔断降级（隔离故障）、监控（实时感知问题）、集群部署（避免单点）。
第（2）步技术选项贯穿始终。需结合业务目标、性能需求和可用性要求综合决策。
一、口诀：
券分模板与记录，MySQL 存 Redis 顶；
库存拆分抗热点，本地缓存二级顶；
MQ 异步来削峰，限流监控保稳定。
二、目标：
高性能、高一致性、高可用。
发券快、不超发、系统不崩溃。
三、方案：
1. 需求拆解与技术选型
（1）需求拆解：
（1）创建优惠券模板（比如满 100 减 50，设置有效期和总库存）
（2）给用户发券（扣减库存，记录谁领了）
（3）处理过期券（没被用的券自动失效，释放库存）
（2）技术选型：
存储：MySQL（持久化券模板和券记录）；
缓存：Redis（缓存券模板和库存，提升读写性能）；
消息队列：RocketMQ（处理券过期逻辑，支持延迟消息）；
系统框架：RPC 框架 Dubbo（服务间通信）。
2. 核心架构与流程设计
（1）系统架构：包含创建券模板、发券、核销券、查券等核心模块，辅以监控报警、风控、对账等辅助模块。
（2）核心流程：
发券流程：参数校验（业务合法性）→ 幂等校验（避免重复发券，基于用户 ID + 订单号）→ 库存扣减（优先扣减 Redis 缓存库存，异步同步至 MySQL）；
券过期处理：通过 RocketMQ 延迟消息循环处理，直至券过期（解决延迟时间超限问题）。
3. 高并发场景解决方案
存储瓶颈优化：
MySQL：读写分离（查询走读库）、分库分表（按 user_id 后四位分片，支持用户维度查询）；
Redis：水平扩容（分片存储，提升读写能力）。
热点库存问题：将热点券模板的库存拆分为多个子库存，随机轮询子库存扣减，分散 Redis 单分片压力。
查询券模板优化：引入本地缓存作为二级缓存（优先查本地缓存→Redis→DB），定时任务同步最新模板信息，减少 Redis 依赖。
4. 服务治理
超时设置：RPC 接口超时设为 500ms，避免上游故障拖垮系统；
监控报警：通过 Grafana 实时监控接口性能、系统资源，异常时及时报警；
限流：对上游服务设置限流规则，避免流量过载；
资源隔离：部署在独立 Docker 集群，避免与其他服务争夺资源。
四、STAR 法则回答
情境（S）：
电商平台春节红包雨活动需发放 1000 万张优惠券，预计峰值 QPS 达 12 万，需保证发放准确、系统稳定。
任务（T）：
设计支持 10 万级 QPS 的高并发优惠券系统，满足高可用（99.99% 可用）、不超发、低延迟（响应 < 500ms）。
行动（A）：
- 技术选型：用 MySQL 存储券数据，Redis 缓存库存，RocketMQ 处理过期券，kitex 作为 RPC 框架；
- 核心设计：发券时先校验参数和幂等性，Redis 扣减库存后异步落库；热点券库存拆分为 20 个子库存，随机扣减；
- 高可用保障：MySQL 读写分离 + 分库分表，Redis 水平扩容；本地缓存减少 Redis 依赖，设置接口超时和限流。
结果（R）：
活动期间系统稳定支撑 13 万 QPS，发券成功率 99.9%，无超发；库存一致性 100%，响应时间 < 300ms，圆满完成活动。
五、生活例子
类比 “电影院售票系统”：
- 券模板类似 “电影票模板”（包含票价、有效期等）；
- 库存拆分如同 “多个售票窗口”，每个窗口卖一部分票，避免单窗口拥挤；
- 本地缓存好比 “窗口售票员的备忘录”，提前记好热门电影的余票，不用每次查总系统；
- 消息队列类似 “退票处理中心”，过期未使用的票自动退回库存，重新售卖。
（一键三连，让算法推荐更多类似干货 ~ 持续更新中，点关注，看下篇文章）
你最近面试被问到的最难的题是什么？ 评论区交流，我来解答。
突然发现自己欠了一屁股 技术债 ？ 别薅头发了 —— 关注本专栏，带你清债～
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
