一种发货通知失败后进行补偿的方法及系统与流程

1.本发明涉及计算机技术领域，特别是一种发货通知失败后进行补偿的方法及系统。


背景技术：

2.在商城系统中，支付系统与发货系统相互隔离，支付服务和发货服务采用微服务的方式进行通信。用户完成订单支付后，支付服务将通知支付成功信息给发货服务，发货服务收到发货通知后进行发货业务。两个服务之间的数据库也是相互独立的，服务之间是使用http的方式进行通知，有可能存在超时、异常等情况。


技术实现要素：

3.为克服上述问题，本发明的目的是提供一种能够保证支付服务发起的发货通知能够有效传达给发货服务，保证能够实现用户发货服务的方法。
4.本发明采用以下方案实现：一种发货通知失败后进行补偿的方法，所述方法包括以下步骤：
5.步骤s1、用户给商城的支付系统付款，支付系统通过创建事件表生成通知事件记录；
6.步骤s2、支付系统在收到用户款项后，向商城的发货系统发起发出货物的通知；
7.步骤s3、判断支付系统通知发货系统发货的通知是否成功，是，则更新事件状态为成功，否，则更新事件记录为失败状态；
8.步骤s4、判断发货系统是否收到支付系统的发货通知，是，则对用户实施发货操作；否，则发货系统启用一个定时任务，定时读取发货通知失败的数据；
9.步骤s5、支付系统将发货通知的失败数据发送至发货系统，实现发货通知能够及时通知，确保发货通知一定能传达的到。
10.进一步的，所述步骤s1进一步具体为：用户付款后，商城的支付系统创建一张事件表notify_event_tb，包含如下字段:通知编号notifyid、订单号orderno、用户编号userid、商品编号goodsid、事件状态state、失败次数failcount、事件时间addtime；用户在支付系统付款后，支付系统在数据库中新增一条事件记录，用于记录发货通知的情况。
11.进一步的，所述步骤s3进一步具体为：生成好通知事件后，商城的支付系统向发货系统发起第一次发货通知，判断发货通知是否成功，是，则主动通知支付系统更新事件状态为成功，否，则在第一次通知失败后间隔10分钟进行第二次通知重试，成功更新事件状态为成功，失败则在第二次通知失败后间隔一个小时进行第三次通知重试，当通知事件记录的失败次数为3次时，则不再进行主动通知发货，记录该通知事件的失败数据。
12.进一步的，所述步骤s4进一步具体为：支付系统在用户支付成功后会向发货系统发送至多3次的发货通知，判断发货系统是否收到支付系统的发货通知，是，则对用户实施发货操作；否，则发货系统启用一个定时任务，向支付系统请求获得通知失败的数据。
13.进一步的，所述步骤s5进一步具体为：支付系统收到发货系统获取发货通知失败数据的请求，将发货通知的失败数据在次日发送至发货系统中，发货系统根据失败数据再次进行发货操作，确保发货业务能够被完成。
14.本发明还提供了一种发货通知失败后进行补偿的系统，包括生成模块、通知模块、判断模块、发货模块和返回数据模块；所述生成模块，即用户给商城的支付系统付款，支付系统通过创建事件表生成通知事件记录；所述通知模块，即支付系统在收到用户款项后，向商城的发货系统发起发出货物的通知；所述判断模块，即判断支付系统通知发货系统发货的通知是否成功，是，则更新事件状态为成功，否，则更新事件记录为失败状态；所述发货模块，即判断发货系统是否收到支付系统的发货通知，是，则对用户实施发货操作；否，则发货系统启用一个定时任务，定时读取发货通知失败的数据；所述返回数据模块，即支付系统将发货通知的失败数据发送至发货系统，实现发货通知能够及时通知，确保发货通知一定能传达的到。
15.进一步的，所述生成模块进一步具体为：用户付款后，商城的支付系统创建一张事件表notify_event_tb，包含如下字段:通知编号notifyid、订单号orderno、用户编号userid、商品编号goodsid、事件状态state、失败次数failcount、事件时间addtime；用户在支付系统付款后，支付系统在数据库中新增一条事件记录，用于记录发货通知的情况。
16.进一步的，所述判断模块进一步具体为：生成好通知事件后，商城的支付系统向发货系统发起第一次发货通知，判断发货通知是否成功，是，则主动通知支付系统更新事件状态为成功，否，则在第一次通知失败后间隔10分钟进行第二次通知重试，成功更新事件状态为成功，失败则在第二次通知失败后间隔一个小时进行第三次通知重试，当通知事件记录的失败次数为3次时，则不再进行主动通知发货，记录该通知事件的失败数据。
17.进一步的，所述发货模块进一步具体为：支付系统在用户支付成功后会向发货系统发送至多3次的发货通知，判断发货系统是否收到支付系统的发货通知，是，则对用户实施发货操作；否，则发货系统启用一个定时任务，向支付系统请求获得通知失败的数据。
18.进一步的，所述返回数据模块进一步具体为：支付系统收到发货系统获取发货通知失败数据的请求，将发货通知的失败数据在次日发送至发货系统中，发货系统根据失败数据再次进行发货操作，确保发货业务能够被完成。
19.本发明的有益效果在于：本发明通过支付系统和发货系统两个服务系统互相配合，如果首次通知成功，则实现及时发货；如果不成功，则进行至多3次的重试通知，进一步确保通知的传达；如果都不成功则发货系统通过补偿接口获取通知失败数据，从而补充了缺失的通知数据，确保发货通知一定能传达的到。
附图说明
20.图1是本发明的方法流程示意图。
21.图2是本发明的系统原理框图。
具体实施方式
22.下面结合附图对本发明做进一步说明。
23.请参阅图1所示，本发明的一种发货通知失败后进行补偿的方法，所述方法包括以
下步骤：
24.步骤s1、用户给商城的支付系统付款，支付系统通过创建事件表生成通知事件记录；
25.步骤s2、支付系统在收到用户款项后，向商城的发货系统发起发出货物的通知；
26.步骤s3、判断支付系统通知发货系统发货的通知是否成功，是，则更新事件状态为成功，否，则更新事件记录为失败状态；
27.步骤s4、判断发货系统是否收到支付系统的发货通知，是，则对用户实施发货操作；否，则发货系统启用一个定时任务，定时读取发货通知失败的数据；
28.步骤s5、支付系统将发货通知的失败数据发送至发货系统，实现发货通知能够及时通知，确保发货通知一定能传达的到。
29.下面通过一具体实施例对本发明作进一步说明：
30.步骤1、用户付款，支付系统生成通知事件记录
31.创建一张事件表notify_event_tb，包含如下字段:通知编号notifyid、订单号orderno、用户编号userid、商品编号goodsid、事件状态state、失败次数failcount、事件时间addtime。用户在支付系统付款后，支付系统在数据库中新增一条事件记录，用于记录发货通知的情况。生成数据如下：通知编号notifyid＝1，订单号orderno＝20211016201459xjfs，用户编号userid＝9990，商品编号goodsid＝201，事件状态state＝0(0代表未通知成功，1代表通知成功，-1代表通知失败并不再进行重试)，失败次数failcount＝0(大于并等于3的将不再通知)，事件时间addtime＝2021-10-16。
32.步骤2、支付系统向发货系统发起发货通知
33.生成好通知事件后，支付系统向发货系统发起第一次发货通知，通知请求如下：https://fahuo.xxx.com/delivery？orderno＝20211016201459xjfs&userid＝9990&sign＝4b34292544a42e29465de6fe52259389。签名sign用于发货系统校验此请求是否合法，签名sign的组织规则是(orderno userid "固定密钥")md5。如果通知成功则进入步骤4，如果通知失败则更新事件记录通知编号notifyid＝1的失败次数failcount加上1。此时失败次数failcount＝1。
34.步骤2.1、第一次通知失败后间隔10分钟进行第二次通知重试，如果通知成功则进入步骤4，如果通知失败则更新事件记录通知编号notifyid＝1的失败次数failcount加上1。此时失败次数failcount＝2。
35.步骤2.2、第二次通知失败后间隔60分钟进行第三次通知重试，如果通知成功则进入步骤4，如果通知失败则更新事件记录通知编号notifyid＝1的失败次数failcount加上1。此时失败次数failcount＝3。
36.步骤3、多次重试通知失败更新事件记录为失败状态
37.如果事件记录的失败次数failcount等于3，表示此次通知已进行3次，3次均失败，则不再进行主动通知，更新事件记录的状态state＝-1，此状态是为了表示那些发货通知是已经发生3次失败并不再主动通知的事件数据，为了步骤5发货系统主动读取补偿数据使用。
38.步骤4、主动通知成功更新事件状态为成功
39.如果步骤2到步骤2.2任何一次通知成功，则会进入此步骤，接收到发货系统返回
success字符串则代表成功，非success都视为失败。成功后，则修改通知事件的state＝1，表示此通知事件发货系统已经收到。
40.步骤5、发货系统收到支付系统的发货通知
41.支付系统在用户支付成功后会进行至多3次的通知，发货系统收到发货通知，得到参数如下orderno＝20211016201459xjfs&userid＝9990&sign＝4b34292544a42e29465de6fe52259389，根据sign组织规则(orderno userid "固定密钥")md5来校验sign和其他参数的合法性，如果生成的sign一致则代表合法。请求合法则对订单20211016201459xjfs向用户9990进行发货操作。
42.步骤6、发货系统定时读取通知失败数据
43.如果步骤2到步骤2.2通知均失败的事件会被步骤3记录为失败状态，发货系统会启用一个定时任务，在每天的凌晨00:00分向支付系统请求获得前一天这些通知失败的数据，假设当下是2021-10-17凌晨，则请求支付系统接口https://zhifu.xxx.com/getnotifyfaildata？time＝2021-10-16&sign＝b705147c2a49dc66908512ea41365f2d，sign组织规则是(time "固定密钥")md5。
44.步骤7、支付系统返回通知失败数据给发货系统
45.支付系统收到获取失败数据请求，得到参数如下：time＝2021-10-16&sign＝b705147c2a49dc66908512ea41365f2d，根据sign组织规则(time "固定密钥")md5来校验sign和其他参数的合法性，如果生成的sign一致则代表合法。根据time参数读取该日期的失败数据，查询语句如下：select*from notify_event_tb where addtime＝'2021-10-16'and state＝-1。那么如果通知3此均失败的话，发货系统可以在次日凌晨从支付系统得到通知失败数据，确保发货业务能够被完成。
46.总之，本发明能够实现发货通知不仅能够及时通知，还需要要求在通知失败后的进行一系列补偿机制，能够使发货通知在失败的情况下，经过支付服务重试通知和发货服务主动获取失败通知两大保障措施，确保发货通知一定能传达的到，本方案要求两个服务系统互相配合，缺一不可。
47.请参阅图2所示，本发明还提供了一种发货通知失败后进行补偿的系统，包括生成模块、通知模块、判断模块、发货模块和返回数据模块；所述生成模块，即用户给商城的支付系统付款，支付系统通过创建事件表生成通知事件记录；所述通知模块，即支付系统在收到用户款项后，向商城的发货系统发起发出货物的通知；所述判断模块，即判断支付系统通知发货系统发货的通知是否成功，是，则更新事件状态为成功，否，则更新事件记录为失败状态；所述发货模块，即判断发货系统是否收到支付系统的发货通知，是，则对用户实施发货操作；否，则发货系统启用一个定时任务，定时读取发货通知失败的数据；所述返回数据模块，即支付系统将发货通知的失败数据发送至发货系统，实现发货通知能够及时通知，确保发货通知一定能传达的到。
48.所述生成模块进一步具体为：用户付款后，商城的支付系统创建一张事件表notify_event_tb，包含如下字段:通知编号notifyid、订单号orderno、用户编号userid、商品编号goodsid、事件状态state、失败次数failcount、事件时间addtime；用户在支付系统付款后，支付系统在数据库中新增一条事件记录，用于记录发货通知的情况。
49.所述判断模块进一步具体为：生成好通知事件后，商城的支付系统向发货系统发
起第一次发货通知，判断发货通知是否成功，是，则主动通知支付系统更新事件状态为成功，否，则在第一次通知失败后间隔10分钟进行第二次通知重试，成功更新事件状态为成功，失败则在第二次通知失败后间隔一个小时进行第三次通知重试，当通知事件记录的失败次数为3次时，则不再进行主动通知发货，记录该通知事件的失败数据。
50.所述发货模块进一步具体为：支付系统在用户支付成功后会向发货系统发送至多3次的发货通知，判断发货系统是否收到支付系统的发货通知，是，则对用户实施发货操作；否，则发货系统启用一个定时任务，向支付系统请求获得通知失败的数据。
51.所述返回数据模块进一步具体为：支付系统收到发货系统获取发货通知失败数据的请求，将发货通知的失败数据在次日发送至发货系统中，发货系统根据失败数据再次进行发货操作，确保发货业务能够被完成。
52.以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所做的均等变化与修饰，皆应属本发明的涵盖范围。