针对商家这些需求,我们引入了限制条件和行为的概念。原先根据规则 id 和充值金额的比较,抽象成了条件的匹配,而权益发放就是满足条件后的行为。
商家为不同的规则定制不同的条件及行为,于是我们的规则成了这样
规则 = 条件 + 行为
那么问题来了,什么样的限制算是规则的条件,而不是规则的某个属性呢?比如作为规则使用范围的商家 id 算条件吗?充值金额呢?
万物皆条件,但是通用的条件就成了属性。比如规则中的商家 id 、业务类型是属性,而充值金额就不是属性,它是储值业务中特有的判断条件。商家运营诉求里的上下线时间,前N名用户参加也是储值业务中的条件。
再来看看行为,权益发放可以认为是一种事后行为,再扩大点看,立减、是否可用的判断都是一种事中行为。值得注意的是,行为的执行并不改变上下文中的原始数据,执行后的结果可作为业务方使用判断的依据,比如立减规则并不改变原订单金额,但是影响最后实际的支付金额。
从系统通用性考虑,许多条件和行为并不是储值业务独有,我们可以定义出多种类型的条件,配以对应的校验器,以便复用。行为也是一样,有对应的执行器,自由组装。基于这样的设计,规则匹配和行为执行可以采用责任链的模式进行处理。
这里条件判断有两点需要思考一下:
有限资源的锁定 - 前文我们谈营销流程时说到,事中营销系统会落下规则订单,事后会进行确认。这类似2PC事务,落下规则订单时需要锁定对应资源(比如名额),事后进行确认或回退,而业务方作为协调方,需要有超时机制触发营销系统回退来释放锁定的资源,以免出现“事务悬挂”。如果没有对资源进行锁定的话,有时会造成产品的用户体验比较差,比如充值时看到前30名送 XXX 优惠券5张,但是付完钱后可能已经是31名了,或者优惠券已经送完了。但是当有限资源不在营销系统时,锁定资源的成本会大大提高,产品上需要在用户体验和系统性能两者之间进行权衡。
临界点的并发处理 - 这是上一个关注点的延伸,在靠近临界值时,如果有限资源不在营销系统,营销系统无法控制并发,只能依赖资源方来维护。在会员储值业务中,典型的并发场景就是首充优惠的判断,营销系统本身无法控制用户的并发充值,对于临界值的判断,需要上游充值平台传递过来。优化上可以与上游系统约定好什么时候传入这个临界资源的数据进行判断,以避免不必要的数据加载。
四、