2024 7.11 day12
https://blog.csdn.net/m0_53934691/article/details/142566492?type=blog&rId=142566492&refer=APP&source=m0_53934691

实现：策略权重装配

在上一节已经能够正常根据策略id装配奖品到redis中的实现，继续实现有rule_weight的策略

  1. 查询策略并装配策略奖品
    • 根据strategyId 在StrategyAward中查找策略奖品实体
    • 依据上一节已经编写好的逻辑，将strategyAward装配到redis中
  2. 获取策略规则实体（含有rule weight的策略）
    • 先查找strategy策略表的rule_model是否含有rule_weight
      • 如果没有，直接退出
      • 如果有，查找strategy_rule策略规则表中含有rule_weight的字段(strategyRuleEntity)
  3. 从strategyRuleEntity中获得对应的权重哈希表，移除策略奖品中没有包含在规则权重中的奖品
    [[充血模型]]

情景

上一节内容我完成了策略奖品的装配，也就是可以按照奖品的概率分配到redis中。比如我们目前的策略是strategy_id = 100001,对应下有ipad抽中的概率是0.5，使用概率值总和除以最小概率值获得奖品总和，将{award_id - i}的map存放到redis中并shuffle. 这样从redis中抽中ipad的概率就是0.5,并且时间复杂度是O（1）.
然而我们还需要设定用户可中奖的范围。比如一共已经消耗了6000积分，那这个用户就属于优质用户，就需要给他更有价值的奖品。

任务

增强抽奖策略装配，实现权重策略的处理，用于满足抽奖中支持不同阶梯所能抽奖范围的处理

行动

  1. 目前的IStrategyArmory接口有两个api(assembleLotteryStrategy用来给一个策略id，装配只需要在活动创建或者审核时候初始化进行的动作。另外一个api getRandomAwardId是给一个策略id进行抽奖。)因此根据保持接口单一职责，避免使用方调用装配操作，拆分装配接口
    • 将getRandomAwardId放在新接口IStrategyDispatch中
  2. 装配实现
    1. 原本是策略全部装配，不需要管rule-weight规则，现在将assembleLotteryStrategy普通规则拆分出来，对rule-weight规则进行处理配置
  3. 在实现策略装配的过程中，有一些实体对象函数和仓库函数需要实现，这一节实现的实体类和仓库函数有以下：
    1. 策略实体(StrategyEntity)实现了ruleModels和getRuleWeight两个函数 ruleModels函数功能是将Strategy表获得的数据检测是否为空，如果不为空返回每一个rulemodel的值，为一个string数组。getRuleWeight的函数功能是从ruleModels字段中获取到RuleWeight数据
    2. 策略规则实体(StrategyRuleEntity), 实现了getRuleWeightValues函数，获取策略规则数据中的权重值，返回一个Map数组
    3. 实现一些策略服务仓的接口。这一步骤的流程很固定
      1. 先在领域层中对应的业务的仓储层创建接口，比如这一节就是(domain–strategy–repository)
      2. 然后跑到基础层的仓储层实现接口(infrastructure–repository–StrategyRepository)
      3. 如果是需要找到数据的接口，开发流程也比较相似。
        1. 首先在redis缓存中查找是否有对应的实体
        2. 如果在redis中查找不到，从库中读取数据，在对应的dao接口中创建query接口，在应用层的mybatis映射中写sql语句

结果

用户可以正确的进行抽奖，并且可以实现，用户当抽奖到一定幸运值，可以抽到更好的奖品