日期：2026-07-11
标签：#面试 #八股 #后端 #系统设计 #场景题
一句话答案
营销事故通常不是单点编码错误，而是规则、资金、发布和风控多道防线同时失效；应通过预算硬约束、规则校验、灰度发布、实时监控和一键止损形成纵深防御。
面试口语版
我会先把它当成资金安全问题，而不只是普通功能 Bug。事前要明确优惠范围、叠加规则、单人和全局预算，并让系统在最底层做不可绕过的额度校验；发布前用真实规则回放、边界测试和双人审核。事中采用小流量灰度，监控核销率、单笔优惠、预算消耗速度等指标，异常时自动熔断活动。事后要能快速关停、冻结异常权益、核对账务，并通过事故复盘补齐测试和审批规则。
原理拆解
- 需求层：规则结构化，避免自然语言歧义；明确时间、地域、用户、商户、商品、支付渠道和叠加关系。
- 资金层：总预算、小时预算、用户限额、订单限额均由服务端原子扣减；宁可少发，不可超发。
- 研发层：决策表测试、边界值测试、历史流量回放、影子验证、配置 Schema 校验。
- 发布层：双人复核，按员工/白名单/城市/比例灰度，配置也要版本化、可回滚。
- 运行层：监控优惠率、核销量突增、预算燃烧率和异常用户聚集度，触发自动熔断。
- 止损层：活动开关、权益冻结、幂等退款、账务对账、证据留存和用户沟通预案。
关键细节
不要只说“加强测试”。高分点是说明如何让错误即使进入生产也无法无限放大：预算硬阈值、异常熔断和小流量灰度是三道核心防线。
面试官追问
- 高并发下如何保证预算不超发？
- 营销规则如何做自动化测试？
- 熔断阈值如何避免误杀？
- 已发放的错误优惠如何处置？
面试官追问参考答案
1. 高并发下如何保证预算不超发？
预算扣减必须放在服务端并使用原子操作。单分片可用 Redis Lua 同时判断余额和扣减，数据库再用 remaining >= amount 的条件更新兜底；成功流水以活动、用户和订单建立唯一约束，异步对账发现不一致。总预算还应按节点或时间段预分配，减少热点竞争。
2. 营销规则如何做自动化测试？
先把人群、时间、商品、渠道、叠加和金额上限转成结构化决策表，再覆盖等价类、边界值、规则组合和互斥条件。发布前用历史生产流量回放和影子计算，将新旧规则结果做 Diff；配置 Schema、预算上限和异常折扣率也应由流水线自动阻断。
3. 熔断阈值如何避免误杀？
阈值应基于正常基线、活动容量和预算燃烧率制定，并组合多个信号，而不是只看单一 QPS。先告警、再小比例限流、最后关停，配合连续窗口、迟滞恢复和人工确认；灰度阶段使用更严格阈值，同时保留白名单验证通道。
4. 已发放的错误优惠如何处置？
先停止继续发放并冻结未使用权益，保留订单和资金证据，再按优惠是否已使用、用户是否善意、金额大小和监管要求分级处理。未使用可撤回，已使用通常通过商户结算调整、补偿或协商处理，不应擅自扣用户资金；所有动作要可审计、可对账并配合客服公告。