一种基于发放引擎的返利处理方案的制作方法

1.本发明涉及it与软件开发/平台领域，特别涉及一种基于发放引擎的返利处理方案。


背景技术：

2.为提高包含电信集团、省公司、翼支付、商户券码权益的发放效率，用户在微信小程序或者app上面领取结果实时性，以确保用户c端无感知领取延迟。对于特殊的场景比如大批量发放或者促销活动的高领取请求的性能要求，保证服务或数据库不会轻易宕机。多元化规则以及众多权益类型的需求。


技术实现要素：

3.本发明要解决的技术问题是克服现有技术的缺陷，提供一种基于发放引擎的返利处理方案，解决等待权益领取结果的用户体验问题，以及众多形式权益发放维护成本大复杂度高的问题。解决后续分省分渠道的营销策略的需要，确保各种情况的性能瓶颈问题。
4.本发明提供了如下的技术方案：
5.本发明提供一种基于发放引擎的返利处理方案，包括以下方案：
6.一、计划中心
7.(1)提供上游有发放需要的平台三个dubbo接口能力，生成发放权益的周期计划的能力、查询能力以及变更计划的能力，类似于一个控制台，上游入口redis cluster集群模式缓存多订单信息，落计划表；再通过定时任务每日按顺序遍历对应返利计划表的数据，满足条件的数据将会去调用发放引擎；
8.(2)暂时归类批量发放、系统周期性发放以及立即发放，每种每笔都需要在在返利计划中心的计划表中落一条记录(主要包含发放时间字段、权益类型、权益说明、发放总次数、当前次数)；
9.(3)为避免大量数据带来的后台数据负担，设计返利计划不是一次性生成，而是在执行第一次计划发放后根据规则判断生成下一期，避免冗余数据，节省更多资源；
10.二、根据不同类型权益产品发放的发放核心
11.(1)由返利计划中心控制专注于各种类型的权益发放，提供返利计划中心一个dubbo发放接口；
12.(2)由发放核心根据权益类型分别调用翼支付券权益、电信集团或省公司的权益发放接口以及商家券码的权益发放接口并记录(数据库对返利记录表进行日期维度拆分，减少了单个数据表的访问压力，提升了数据库访问性能)；
13.(3)通过elastic-job定时任务轮询查询发放中的记录，其中定时任务采用多分片算法来解决大量某时间段发放中记录去查询获取结果，再提供dubbo回调接口和开发对接对应结果信息的kafka的消费者来更快获取省公司、营销部门等异步发放接口平台的发放结果；
14.(4)通配一个kafka生产者将所有类型的结果信息立刻推送给返利计划中心。
15.与现有技术相比，本发明的有益效果如下：
16.本发明对现有权益发放流程进行优化，对权益业务发放业务进行拆分成专注规则的返利计划平台以及专注权益类型发放，改善处理逻辑；简化了开发流程，提高了高发效率，降低了后端人员的开发成本。提高包含电信集团、省公司、翼支付、商户券码权益的发放效率，用户在微信小程序或者app上面领取结果实时性，以确保用户c端无感知领取延迟。对于特殊的场景比如大批量发放或者促销活动的高领取请求的性能要求，保证服务或数据库不会轻易宕机，同时满足多元化的权益发放形式需求而增加发放的复杂度。
附图说明
17.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
18.图1是本发明的框架结构图；
19.图2是本发明的实施例示意图。
具体实施方式
20.以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。
21.实施例1
22.如图1-2，本发明提供一种基于发放引擎的返利处理方案，包括以下：
23.一、计划中心
24.(1)提供上游有发放需要的平台三个dubbo接口能力，生成发放权益的周期计划的能力、查询能力以及变更计划的能力，类似于一个控制台，上游入口redis cluster集群模式缓存多订单信息，落计划表；再通过定时任务每日按顺序遍历对应返利计划表的数据，满足条件的数据将会去调用发放核心；
25.(2)暂时归类批量发放、系统周期性发放以及立即发放，每种每笔都需要在在返利计划中心的计划表中落一条记录(主要包含发放时间字段、权益类型、权益说明、发放总次数、当前次数)；
26.(3)为避免大量数据带来的后台数据负担，设计返利计划不是一次性生成，而是在执行第一次计划发放后根据规则判断生成下一期，避免冗余数据，节省更多资源；
27.二、根据不同类型权益产品发放的发放引擎
28.(1)由返利计划中心控制专注于各种类型的权益发放，提供返利计划中心一个dubbo发放接口，
29.(2)由发放核心根据权益类型分别调用翼支付券权益、电信集团或省公司的权益发放接口以及商家券码的权益发放接口并记录(数据库对返利记录表进行日期维度拆分，减少了单个数据表的访问压力，提升了数据库访问性能)；
30.(3)通过elastic-job定时任务轮询查询发放中的记录，其中定时任务采用多分片算法来解决大量某时间段发放中记录去查询获取结果，再提供dubbo回调接口和开发对接
对应结果信息的kafka的消费者来更快获取省公司、营销部门等异步发放接口平台的发放结果；
31.(4)通配一个kafka生产者将所有类型的结果信息立刻推送给返利计划中心，利用kafka消息队列的优势迅速返回更新结果返回给其他多个调用方。
32.最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。


技术特征：
1.一种基于发放引擎的返利处理方案，其特征在于，包括以下方案：一、计划中心(1)提供上游有发放需要的平台三个dubbo接口能力，生成发放权益的周期计划的能力、查询能力以及变更计划的能力，类似于一个控制台，上游入口redis cluster集群模式缓存多订单信息，落计划表；再通过定时任务每日按顺序遍历对应返利计划表的数据，满足条件的数据将会去调用发放引擎；(2)暂时归类批量发放、系统周期性发放以及立即发放，每种每笔都需要在在返利计划中心的计划表中落一条记录(主要包含发放时间字段、权益类型、权益说明、发放总次数、当前次数)；(3)为避免大量数据带来的后台数据负担，设计返利计划不是一次性生成，而是在执行第一次计划发放后根据规则判断生成下一期，避免冗余数据，节省更多资源；二、根据不同类型权益产品发放的发放核心(1)由返利计划中心控制专注于各种类型的权益发放，提供返利计划中心一个dubbo发放接口；(2)由发放核心根据权益类型分别调用翼支付券权益、电信集团或省公司的权益发放接口以及商家券码的权益发放接口并记录(数据库对返利记录表进行日期维度拆分，减少了单个数据表的访问压力，提升了数据库访问性能)；(3)通过elastic-job定时任务轮询查询发放中的记录，其中定时任务采用多分片算法来解决大量某时间段发放中记录去查询获取结果，再提供dubbo回调接口和开发对接对应结果信息的kafka的消费者来更快获取省公司、营销部门等异步发放接口平台的发放结果；(4)通配一个kafka生产者将所有类型的结果信息立刻推送给返利计划中心。

技术总结
本发明公开了一种基于发放引擎的返利处理方案；本发明对现有权益发放流程进行优化，对权益业务发放业务进行拆分成专注规则的返利计划平台以及专注权益类型发放，改善处理逻辑；简化了开发流程，提高了高发效率，降低了后端人员的开发成本；提高包含电信集团、省公司、翼支付、商户券码权益的发放效率，用户在微信小程序或者APP上面领取结果实时性，以确保用户C端无感知领取延迟；对于特殊的场景比如大批量发放或者促销活动的高领取请求的性能要求，保证服务或数据库不会轻易宕机。保证服务或数据库不会轻易宕机。保证服务或数据库不会轻易宕机。


技术研发人员：程晨 李伟 李兵 任子斌
受保护的技术使用者：天翼电子商务有限公司
技术研发日：2021.12.30
技术公布日：2022/5/25