订单推送设计思路-基于支付ID而不是订单号来推送

订单推送设计思路-基于支付ID而不是订单号来推送

方案：不是基于订单号来核销和分账的，抖音是基于每一笔抖音支付来做订单推送，核销和分账
现象：这样会在抖音的订单中心中会出现很多条订单推送的记录。

抖音App订单列表状态如下：待支付,已取消,已支付,已核销

抖音文档地址
订单同步
https://developer.open-douyin.com/docs/resource/zh-CN/mini-app/develop/server/ecpay/order/order-sync

1.发送订单支付成功事件，根据MQ消息中定义的type来区分不同的支付项目

2.定时任务的关键参数，商家订单号，支付金额，支付时间，在使用公用模块，公用方法中，需要替换成当前定时任务JOB的当前对象的关键参数：商家订单号，支付金额，支付时间
定时任务的outOrderNo payTime payAmt 不取公共方法中，而是取的定时任务的当前记录的outOrderNo payTime payAmt

3.BeanUtils.copyProperties 对象属性覆盖方法慎用，避免将无关的属性被覆盖了。Integer与String属性类型不对，这个需要注意。

4.定时任务处理推送的时候，需要过滤已经推送的记录。无需重复推送

5.加上日志 “抖音推送” 等关键字，便于日志检索，类似RequestId功能，同时在try-catch 异常捕获中也需要加上该关键字。

6.循环思路
* 构建终止退出机制
* 构建新的记录循环机制
* 构建记录之间不相互,循环中某一条异常了，对其他的循环对象不影响中断。
初始化下一次的记录，及备份当前成功的记录(逻辑删除,转移到备份表,新增下一次定时任务分账的记录)

7.兜底，闭环思路
订单开始时间，到订单结束时间，考虑将订单结束时间收尾。将不同的业务规则最终归一到一套规则来。