千万级商品组合营销价格自动计算引擎采用规则树替代嵌套循环，通过位图、倒排索引、分桶归并实现轻量执行；结合分层缓存预计算高频Bundle价格；对动态组合实施前端约束、服务端熔断与价格快照；引擎无状态，仅依赖RPC输入输出标准化PriceCalcResult。
千万级商品组合的营销价格自动计算引擎，不能靠嵌套循环硬扛实时计算。核心思路是：**把“循环嵌套”从运行时搬进规则编译期和数据组织层，让实际执行变成查表、匹配、聚合三类轻量操作。**
用规则树替代多层for循环
传统做法是遍历商品池→筛选组合→校验促销条件→计算叠加优惠，四层嵌套在千万量级下必然超时。实战中应将促销逻辑抽象为可执行规则树（如Drools或自研表达式引擎），每个节点对应一个原子条件（如“SKU属于A品类且库存>0”、“用户等级≥VIP2”）。引擎只做一次DFS遍历，不重复构造中间集合。例如：
- 组合生成阶段：用位图（BitSet）表示商品ID集合，用整数运算代替List嵌套遍历；
- 规则匹配阶段：预编译条件为倒排索引（如“满300减50”规则映射到所有价格≥300的商品ID列表）；
- 价格叠加阶段：按优惠类型分桶（直降、折扣、赠品），各桶内仅做一次归并排序+贪心选取，避免全排列。
分层缓存 + 预计算组合价格
真实业务中，80%的热销组合是有限的（如“iPhone+AirPods+保护壳”）。引擎需主动识别高频Bundle模式：
- 离线层：用Flink实时统计加购共现频次，每日产出Top 10万Bundle ID及其基准价；
- 近线层：Redis Cluster中以Bundle ID为key，存储预计算的“阶梯价+可用优惠券列表”，TTL设为2小时；
- 在线层：用户请求时，先查Bundle缓存；未命中再走规则树兜底，结果异步回填缓存。
动态组合的轻量级运行时裁剪
当用户自主拖拽商品构建Bundle（如定制PC），必须限制实时计算复杂度：
- 前端强制约束：最多选5个SKU，且至少含1个主商品（如CPU），规避全量笛卡尔积；
- 服务端熔断：对Bundle内商品按类目聚类（如“主板/内存/显卡”三类），每类只取价格Top3参与优惠叠加计算；
- 价格快照机制：首次加载Bundle时，调用结算中心获取带时效的价格快照（含库存状态、可用券、满减门槛），后续勾选/去勾只做增量重算，不重复RPC。
与购物车系统解耦，专注“计算”本身
参考千万级购物车架构设计，价格计算引擎必须保持无状态、可水平伸缩：
- 输入仅为Bundle商品ID列表 + 用户上下文（ID、等级、地域、设备）；
- 不保存购物车数据，不读写Redis购物车结构，所有依赖通过同步RPC调用结算中心、营销服务、用户中心；
- 输出严格定义为PriceCalcResult对象：含总金额、各商品明细价、叠加优惠明细、失效原因（如“赠品库存不足”），供前端精准展示和兜底提示。
