北京云集Java（AI方向）一面面经

面试题目

1. 你理解的电商营销体系中，商品的价格体系是怎么计算出来的？
2. 讲一下你负责的优惠券接口的业务背景，以及整体的架构设计？
3. 对于满减、包邮、N 元 N 件、N 件 N 折等底层玩法和核销模型完全不同的券，用工厂模式如何做统一抽象？
4. 如果从零搭建一个优惠券资产管理平台，你认为策略工厂的 Map 中，value 对应的策略对象，至少应该包含哪些核心内容？
5. 从资损防控的角度，你会如何设计优惠券系统的风控相关策略？
6. 订单交易和商品中心的分布式事务，解决了什么业务问题？你的设计思路是怎样的？
7. 如果三方支付在大促场景下超时，超出了 5 分钟的延迟关单阈值，但用户实际已支付成功，这个链路你要怎么处理？
8. 简单介绍一下 TCC 分布式事务是怎么工作的？它的核心设计思想是什么？

参考解析

1. 优惠券工厂模式抽象：定义统一的接口或抽象类（如 PromotionStrategy），包含 check()（校验条件）和 calculate()（计算优惠后价格）方法。工厂通过 Map 映射策略类型与实例，实现开闭原则，新增营销活动仅需添加策略实现类，无需修改原业务逻辑。

2. 策略工厂 Map 的核心内容：应包含策略执行逻辑（Strategy）、规则解析器（解析 JSON 配置）、规则校验器（验证参数合法性）、以及活动执行的优先级权重（用于多券叠加顺序）。

3. 资损防控策略：需建立防重幂等机制、限流熔断、优惠券核销的强一致性校验。在后台需有“额度封顶”逻辑防止超领，并引入异步对账系统对比订单快照与优惠券状态，确保资金流闭环。

4. 支付超时处理：采用“补偿机制”或“补单逻辑”。系统需主动调用支付平台查询订单状态接口（Query），若确认已支付，则触发下游订单系统的补单流程（更新订单状态为已支付、扣减库存、异步通知库存中心）。

5. TCC 分布式事务：核心是“Try-Confirm-Cancel”。Try 阶段做业务检查与预留资源；Confirm 阶段执行真正业务逻辑；若任一环节失败，Cancel 阶段释放 Try 阶段预留的资源。核心思想是将两阶段提交的锁力度细化到应用层，保证最终一致性。