静态资格匹配
为了更加通用性在设计中可以设置规则匹配的入参为Map形式，在进行匹配前需要把静态资格数据转化为Map数据格式，然后在生成的KieBase中获取KieSession，通过此KieSession进行规则匹配。
KieSession需要设置全局的一个集合，来返回匹配到相关活动编码数据，同时需要考虑活动是有状态和有效期的，所以在拿到静态数据匹配的活动编码后，需要对活动的状态进行筛选，拿到的是生效且在有效期范围内的活动。
动态资格
此处动态资格主要是指活动的次数和用户次数。营销活动为了能够使更多的用户能够参与，防止某些用户的重复参与，会对用户的每日、每月、总参与次数进行限制，同时活动的经费是有限的，为了能够使营销活动效果做的更好，也会对活动的每日、每月、总次数进行限制。
动态资格设计可以分为两个维度，一个是对象，一个是周期：
通过上图设计，周期维度确认好后变更的可能性比较小，可以在前期调研阶段确认好周期范围。不过，对象变更相比较周期而言会更频繁，前期系统上线的时候确认一个自然人可能只有帐号、绑定手机两个属性，后期通过系统的不断迭代及技术的不断进步这个属性可能会进行扩容。所以，在进行架构设计的时候需要考虑具体对象的扩展性。同时，为了高并发的查询、次数的扣减或者回滚，可以通过缓存来代替数据库的记录和操作，当然为了保证数据的可恢复性，可以设计实时缓存，异步落库的操作。
动态资格组装
资格组装按照分析，采用抽象类封装内部实现，每个对象通过继承抽象类，实现具体的抽象方法的方式来实现。
抽象类AbstractDimensionDynamic中有两个抽象方法获取对象targetType和获取对象值targetValue是在具体类中进行实现。dynamicAssemble方法是进行dynamicKey的拼接并组装动态资格的具体对象，最终得到动态资格对象的集合。
AbstractDimensionDynamic的子类是具体的动态资格对象，每增加一个对象，通过增加子类的方式来实现。
动态资格服务
此处设计中DynamicService对外提供的是动态资格校验和动态资格扣减两个服务，在实际过程中还会存在回退的服务，这个需要自行进行扩展。
抽象类AbstractDynamicService中的dimensionDynamics是一个List，并且注解为@Autowired，Spring会自动从容器中取出DimesionDynamic的实现类装配到List类型的dimensionDynamics中，从而简化了依赖注入的过程，并且有新增实现类的时候系统启动会自动注入。
@Autowired private List<DimensionDynamic> dimensionDynamics; @Resource private RedisService redisService;
其中的assembleDynamicRecordList方法是通过遍历dimensionDynamics，组装需要的查询或者扣减的动态数据记录；rollback方法是扣减出现异常或者扣减超过限制后进行回滚使用的操作，此方法需要抛出异常，供上游判断是否需要进行处理。
缓存使用Redis，主要是考虑在redis中的incrBy和decrBy都是原子性操作，这个在高并发的场景中防止由于并发导致的累计错误问题。而且redis的mget命令可以批量查询，主要是由于redis使用基于RESP协议的rpc接口，而redis本身的数据结构非常高效，所以IO和协议解析是个不容忽略的资源消耗。通过mget将多个get请求汇聚成一条命令，可以大大降低网络、rpc协议解析的开销，从而大幅提升缓存效率。
DynamicServiceImpl是DynamicService的具体实现，并且要继承AbstractDynamicService抽象类。需要实现dynamicChack动态资格校验和dynamicDeduction动态资格扣减方法。
动态资格校验是通过组装的动态记录数据集，到缓存中查询目前存储的值跟对应动态资格最大值进行比较，当缓存值大于等于最大值表示动态资格校验不通过。
动态资格扣减使用缓存的incrBy进行累加，这块需要针对每个累加后进行判断来减少跟缓存的交互，并且需要把已经累加的数据进行记录，提供回滚资格使用。
以上是针对营销系统的资格设计的一个设计思路和相关实践的简单案例，在具体设计中需要考虑的问题比案例中的更加复杂。比如：用户资格不满足原因的输出、异步动态资格数据入库处理、动态资格校验返回所有不满足原因等等。这些就需要进行相关的扩展和针对目前公司的基础配套设施的情况进行选择设计。
作者介绍 ：
王海民，苏宁金融研发中心高级技术经理，主要负责苏宁金融会员及互联网研发中心的营销部门工作。具有营销、电商、支付、金融等相关领域 10 年以上工作经历；擅长互联网产品服务端应用技术架构。
