1.抽奖策略领域抽奖策略装配1.奖品列表配置通过strategyId查询strategy_award数据库把奖品概率转换为数量List存入Redis配置了权重策略查询数据库strategy_rule解析权重值映射遍历权重规则为每个规则创建独立概率表不同级别的用户奖品不同缓存奖品库存利用Redis缓存奖品库存后续一致性通过redis阻塞队列和定时任务延迟处理2.抽奖逻辑生成随机数通过该随机数查询奖品列表![[Pasted image 20251230160923.png]]抽奖执行流程模板模式AbstractRaffleStrategy类定义抽奖的标准流程奖品参数校验抽奖前 - 规则过滤责任链模式责任链工厂组装责任链通过redis缓存或数据库获取黑名单权重配置默认配置抽奖中 - 规则过滤规则树模式规则树工厂组装规则树次数限定库存检查使用Atomic操作执行扣减使用setnx锁住库存过期时间为活动结束时间兜底策略返回抽奖结果2.抽奖活动领域sku解耦不同的场景下所需要在一个活动上给用户分配的抽奖次数不同的情况抽奖活动装配1.sku活动列表配置通过sku查询raffle_activity_sku表缓存sku下的库存和raffle_activity_count表中记录的对应参与次数预热raffle_activity活动介绍信息2.通过活动ID配置通过活动ID查询该活动下所有的sku并循环缓存第一步购买活动订单模板模式AbstractRaffleActivityAccountQuota类定义创建订单标准的流程购买、兑换、打卡增加抽奖次数参数校验查询未支付订单查询基础信息账户额度校验活动动作规则校验责任链日期过滤库存过滤构建订单聚合对象执行交易策略保存订单返回单号创建活动订单模板模式AbstractRaffleActivityPartake类定义参与活动创建订单的标准流程活动查询校验活动状态校验活动日期「开始时间 - 当前时间 - 结束时间」查询未被使用的活动参与订单记录额度账户过滤返回账户构建对象查询总账户额度查询月账户额度查询日账户额度构建订单填充抽奖单实体对象保存聚合对象返回订单信息3.奖品发放领域通过AwardService保存中奖记录使用MQ推送奖品和定时任务执行任务补偿4.返利服务领域1.通过BehaviorRebateService创建返利订单查询返利配置构建聚合对象1.返利订单拼装业务ID保证幂等性2.MQ task任务存储聚合对象数据返回订单ID集合2.RebateMessageCustomer实现返利入账转换消息入账奖励1.sku类型调用活动领域进行入账2.积分类型调用积分调额领域进行入账5.积分调额领域1.通过CreditAdjustService进行积分调额1.构建交易聚合对象创建账户积分实体创建账户订单实体构建消息任务对象2.保存积分交易订单积分账户更新积分订单创建3.写入任务发生积分调整成功消息后续由消费者更新订单状态6.抽奖流程串联1.通过RaffleStrategyController整合策略相关api1.策略装配预热2.查询奖品列表参数校验查询奖品配置通过活动ID获取规则配置 - 查询规则配置 - 获取奖品的解锁限制抽奖N次后解锁查询抽奖次数 - 用户已经参与的抽奖次数遍历填充数据 - 返回结果3.随机抽奖4.查询账户余额5.查询sku商品6.查询用户积分值7.积分兑换sku创建活动订单用户账户调额2.通过RaffleActivityController整合活动相关api1.活动装配预热2.参与活动抽奖参数校验参与活动 - 创建参与记录订单抽奖策略 - 执行抽奖存放结果 - 写入中奖记录返回结果3.日历签到返利7.算法优化算法1O(1) 时间复杂度算法在抽奖活动开启时将奖品概率预热到本地(Guava)/Redis。如10%的概率可以是占了110的数字区间对应奖品A。1115 对应奖品B。那么在抽奖的时候直接用生成的随机数通过对 map 进行 get 即可。算法2是O(n) ~ O(logn)算法当奖品概率非常大的时候达到几十万以上我们就适合在本地或者 Redis 来初始化这些数据存到 Map 里了。那么这个时候就要把奖品概率拆分为一个个有限定范围的格子区间。比如 17900代表一个奖品、79018200代表另外一个奖品把这些数据存储到MapMapInteger,Integer,Integer在抽奖的时候通过产生的随机值来与这些范围区间依次进行对比。那么为了更好的优化抽奖算法可以的分别对8的进行for循环、16的二分查找、16的进行多线程计算。附录责任链责任链需要一个规则接口一个组装规则的接口一个抽象类来填充责任链。之后是实现责任链接口的各个具体要处理的规则操作比如活动基础信息校验活动库存处理。此外还有一个责任链的处理工厂负责将各部分责任链对象注入进来后加工组装出一个责任链的链条。就像我们讲的这个责任链是一个固定结构的链接所以在工厂中提供个统一的链就可以了。动态配置以Zookeeper为配置中心服务基于 Zookeeper 的节点监听值变更机制动态修改应用程序中属性值。首先我们需要定义出一个 Zookeeper 监听的配置路径一般这个路径在配置中心中是申请的系统使用地址以确保值的唯一。之后每个类对应的属性需要映射出一个监听的节点。比如Zookeeper 监听了 /big-market-dcc/config 那么类中 a 属性可以是 /big-market-dcc/config/a 这对这个路径设置的值就可以被监听拿到了。最后把获取到的监听值通过 Java 反射操作把值设置到对应的属性上。这样在 SpringBoot 应用程序中使用某个类的属性值的时候就可以动态的获取到变化的属性值了。熔断与限流DDD的基础概念1.充血模型充血模型Rich Domain Model将业务逻辑封装在领域对象内部对象既包含数据也包含操作这些数据的方法符合面向对象设计原则贫血模型Anemic Domain Model只包含数据不包含业务逻辑业务逻辑放在服务层或管理器层违反面向对象设计原则Martin Fowler称为反模式2.领域模型领域模型指特定业务领域内业务规则、策略以及业务流程的抽象和封装。在设计手段上通过风暴模型拆分领域模块形成界限上下文。最大的区别在于把原有的众多 Service 数据模型的方式拆分为独立的有边界的领域模块。每个领域内创建自身所属的领域对象实体、聚合、值对象、仓储服务(DAO 操作)、工厂、端口适配器Port调用外部接口的手段等。2.1 实体、聚合、值对象实体是依托于持久化层数据以领域服务功能目标为指导设计的领域对象。概念实体 唯一标识 状态属性 行为动作功能是DDD中的一个基本构建块它代表了具有唯一标识的领域对象。实体不仅仅包含数据状态属性还包含了相关的行为功能并且它的标识在整个生命周期中保持不变。值对象这个对象在领域服务方法的生命周期过程内是不可变对象也没有唯一标识。它通常是配合实体对象使用如为实体对象提供对象属性值的描述。聚合当你对数据库的操作需要使用到多个实体时可以创建聚合对象。一个聚合对象代表着一个数据库事务具有事务一致性。概念聚合是领域模型中的一个关键概念它是一组具有内聚性的相关对象的集合这些对象一起工作以执行某些业务规则或操作。聚合定义了一组对象的边界这些对象可以被视为一个单一的单元进行处理。实体为了管理有生命周期、会变化的业务对象值对象为了封装不变的概念和验证规则聚合为了维护一组相关对象的数据一致性2.2 仓储和适配器在 DDD 的设计方法中领域层做到了只关心领域服务实现。最能体现这样设计的就是仓库和适配器的设计。通常在 Service 数据模型的设计中会在 Service 中引入 Redis、RPC、配置中心等各类其他外部服务。但在 DDD 中通过仓储和适配器以及基础设施层的定义解耦了这部分内容。