通用的合理的状态流转,可以快速定位区分 C 端用户的任务完成情况,失败和终止的业务可以依赖定时任务做任务完成重放,快速推进到完结,并发放奖励,规避异常给用户带来的奖励信息不同步的问题,保证系统内的一致性。
三、我们使用了哪些核心技术组件?
3.1 幂等控制组件
3.1.1 为什么要要使用幂等组件
在任务中心落地中,很多场景需要控制任务的唯一幂等,多次发放不会重发等等。之前我们主要是通过 db 幂等表,插入业务唯一索引来保证幂等,但是需要数据库的事务保证,即幂等流水和业务要一起提交,失败即回滚。当使用到多库的场景时,业务系统每个库都要增加一张流水表,并且控制本分片内业务 id 和分片 id 一致,比较繁琐。还有一部分内部系统使用分布式存储(比如 redis),来保存业务请求记录。服务端在接收到请求后,用原子性的查询和保存操作(比如 redis 的 setnx 命令),来保证业务唯一流水落到存储中,在业务设置的超时时间前,控制业务流水的幂等。当发现重复流水时,按照一定的策略返回。在任务中心系统落地时,同时保留了两种模式,并且还要考虑接入方依赖的存储的拓展性和快速接入。
3.1.2 幂等组件的规则
幂等使用支持注解方式快速接入+spEL 表达式拼接幂等入参信息。
基于 apollo 的动态配置推送。
幂等存储策略:
1.缓存 redis 存储(优先)2.mysql 存储等
幂等拒绝策略:
1.多次返回相同结果 2.返回幂等码 3.抛出异常等
3.1.3 幂等组件的设计
通过基础的工具 jar 包,承载整个幂等组件逻辑,达到快速接入的目的,通过 apollo 可以动态推送相关配置,达到业务系统快速切换分支,随时线上应急。
3.3 动态配置变更组件 目前很多基础配置都是通过依赖配置文件,或者 apollo 的动态配置。但是这两种方式都是有一定优缺点的:配置文件的方式,虽然存储容量没有限制,但是配置变更后,需要重启应用,比较复杂。而 apollo 开关的方式虽然可以动态变更,但是存储的配置信息很少,有一定长度限制。对于任务中心这种多任务平台型的配置,有一定影响。所以最后使用了基于 jvm+apollo 的延时加载的策略,即保证了不用频繁发布,同时可以动态变更配置信息。