本發明(ming)涉(she)(she)及(ji)(ji)互聯(lian)網分布式(shi)微服(fu)務架構，尤其涉(she)(she)及(ji)(ji)一種(zhong)基于遞(di)增定(ding)時補償異步通知支付結果的方(fang)法及(ji)(ji)系統。

背景技術：

1、核(he)心支付(fu)(fu)(fu)系(xi)統(tong)(tong)通過對(dui)接(jie)銀聯(lian)以及網(wang)聯(lian)來完(wan)(wan)成(cheng)交(jiao)易訂單(dan)的(de)(de)創建(jian)，完(wan)(wan)成(cheng)以及退(tui)款。當一(yi)(yi)(yi)筆支付(fu)(fu)(fu)訂單(dan)完(wan)(wan)成(cheng)支付(fu)(fu)(fu)以后，銀聯(lian)或(huo)者(zhe)(zhe)網(wang)聯(lian)會(hui)將支付(fu)(fu)(fu)結(jie)果(guo)(guo)異步通知(zhi)(zhi)給核(he)心支付(fu)(fu)(fu)系(xi)統(tong)(tong)，再由核(he)心支付(fu)(fu)(fu)系(xi)統(tong)(tong)同步支付(fu)(fu)(fu)結(jie)果(guo)(guo)到(dao)e賬(zhang)(zhang)通系(xi)統(tong)(tong)，最后e賬(zhang)(zhang)通系(xi)統(tong)(tong)通知(zhi)(zhi)給各(ge)商(shang)戶(hu)完(wan)(wan)成(cheng)一(yi)(yi)(yi)筆訂單(dan)的(de)(de)閉環業務。但是由于網(wang)絡問題或(huo)者(zhe)(zhe)其(qi)他原因(yin)時(shi)常會(hui)導(dao)致商(shang)戶(hu)平臺接(jie)受不到(dao)e賬(zhang)(zhang)通系(xi)統(tong)(tong)通知(zhi)(zhi)的(de)(de)交(jiao)易結(jie)果(guo)(guo)，或(huo)者(zhe)(zhe)反饋給e賬(zhang)(zhang)通系(xi)統(tong)(tong)的(de)(de)處理(li)結(jie)果(guo)(guo)系(xi)統(tong)(tong)沒(mei)有收(shou)到(dao)，e賬(zhang)(zhang)通系(xi)統(tong)(tong)不能(neng)一(yi)(yi)(yi)直(zhi)(zhi)發送異步通知(zhi)(zhi)給商(shang)戶(hu)平臺，因(yin)為這(zhe)樣會(hui)極大的(de)(de)造成(cheng)連接(jie)資源浪費，會(hui)一(yi)(yi)(yi)直(zhi)(zhi)重復(fu)通知(zhi)(zhi)商(shang)戶(hu)平臺。這(zhe)個(ge)時(shi)候就需要一(yi)(yi)(yi)個(ge)補償通知(zhi)(zhi)支付(fu)(fu)(fu)結(jie)果(guo)(guo)的(de)(de)機制。

技術實現思路

1、針對現有技術中存(cun)在(zai)的技術問題(ti)，本發明提供一種(zhong)基于(yu)遞增(zeng)定時補償異步(bu)(bu)通知支付結(jie)果(guo)(guo)的方法(fa)，提供一種(zhong)基于(yu)遞增(zeng)定時補償異步(bu)(bu)通知支付結(jie)果(guo)(guo)的技術方案，能夠按(an)時準時的補償異步(bu)(bu)通知到商戶平(ping)臺交易結(jie)果(guo)(guo)。

2、根據本(ben)發明(ming)的第一(yi)方(fang)面，本(ben)發明(ming)提供一(yi)種(zhong)基(ji)于遞增(zeng)定時(shi)補償(chang)異步(bu)通知支付結果的方(fang)法，包括以下步(bu)驟(zou)：

3、e賬通(tong)(tong)交易模塊收到核心支(zhi)(zhi)付(fu)平(ping)臺的(de)訂單(dan)支(zhi)(zhi)付(fu)結(jie)果后，封裝并(bing)發布事件通(tong)(tong)知消息讓所述(shu)訂單(dan)支(zhi)(zhi)付(fu)結(jie)果進入通(tong)(tong)知流程；

4、e賬(zhang)通(tong)(tong)(tong)(tong)(tong)(tong)交易子(zi)模塊收到(dao)(dao)通(tong)(tong)(tong)(tong)(tong)(tong)知(zhi)消息后，對平(ping)臺(tai)商戶(hu)進行(xing)首次(ci)通(tong)(tong)(tong)(tong)(tong)(tong)知(zhi)處(chu)理(li)(li)；其中，在通(tong)(tong)(tong)(tong)(tong)(tong)知(zhi)消息發送前，設(she)置失敗最大(da)次(ci)數(shu)、每次(ci)發送的時(shi)間間隔和(he)通(tong)(tong)(tong)(tong)(tong)(tong)知(zhi)次(ci)數(shu)；如果首次(ci)通(tong)(tong)(tong)(tong)(tong)(tong)知(zhi)發送成功，流(liu)程結束；如果首次(ci)通(tong)(tong)(tong)(tong)(tong)(tong)知(zhi)失敗，則進入(ru)到(dao)(dao)消息通(tong)(tong)(tong)(tong)(tong)(tong)知(zhi)的補(bu)(bu)發處(chu)理(li)(li)階段；此時(shi)，定時(shi)任務(wu)檢索數(shu)據庫表(biao)，查找(zhao)待補(bu)(bu)發的通(tong)(tong)(tong)(tong)(tong)(tong)知(zhi)消息，并發送到(dao)(dao)延時(shi)處(chu)理(li)(li)隊列進行(xing)補(bu)(bu)發處(chu)理(li)(li)；直(zhi)到(dao)(dao)補(bu)(bu)發成功或者補(bu)(bu)發失敗次(ci)數(shu)達(da)到(dao)(dao)上限，進行(xing)人工介入(ru)。

5、在上述技術方案的基礎上，本發明(ming)還可以作(zuo)出如下改(gai)進。

6、可選的，所述e賬通交易模塊(kuai)收到核心支(zhi)付平臺的訂單最終(zhong)結果，封裝(zhuang)并(bing)發布kafka事件event_topic。

7、可(ke)選的，所述e賬通交易模塊收到核心支(zhi)付(fu)平臺的訂(ding)單(dan)支(zhi)付(fu)結果(guo)后，封(feng)裝并發布事件通知(zhi)消息讓所述訂(ding)單(dan)支(zhi)付(fu)結果(guo)進(jin)入通知(zhi)流(liu)程包括：

8、步驟1.1：消息通知模(mo)塊首(shou)次發送隊(dui)列(lie)接收到通知消息后設置(zhi)最大失(shi)敗(bai)發送次數(shu)，和(he)每次發送時間間隔；

9、步驟1.2：e賬通(tong)交(jiao)易模塊(kuai)通(tong)知向商(shang)戶發送交(jiao)易通(tong)知；如果通(tong)知發送失敗，則進(jin)行(xing)補發處理；當(dang)小于預(yu)設的時間，發送到延(yan)時處理隊列(lie)；

10、步驟1.3：延時隊列(lie)等待初始默認值后(hou)，將補發通知(zhi)交給補發隊列(lie)處理，并執行通知(zhi)補發邏輯。

11、可選的(de)(de)，所(suo)述(shu)最大失敗發(fa)送次(ci)(ci)數為對應的(de)(de)11次(ci)(ci)，其中，首次(ci)(ci)發(fa)送為1次(ci)(ci)。

12、可選的，所述每次(ci)發送時間間隔(ge)設(she)置為以(yi)下(xia)任(ren)一種：

13、0s,5s,10s,2min,5min,10min,30min,1h,2h,6h,15h，其中，0s為消(xiao)息通知首(shou)次發送時設置的默認值(zhi)。

14、可選(xuan)的，所述e賬通交易子模塊webhook收(shou)到(dao)kafka事件event_topic后，對平臺商戶進行(xing)首次通知處理。

15、可選的(de)，所述定時任(ren)務(wu)檢索數(shu)據庫表，查找待補(bu)發的(de)通知消息，并(bing)發送到(dao)延時處理隊列進(jin)行補(bu)發處理；直(zhi)到(dao)補(bu)發成功或(huo)者補(bu)發失(shi)敗次數(shu)達到(dao)上限，進(jin)行人工(gong)介入包(bao)括：

16、步驟(zou)2.1：延時(shi)通(tong)知隊列收集來源于首(shou)次的通(tong)知失敗的，以(yi)及定時(shi)任務(wu)每分鐘查檢索數據(ju)庫表(biao)中將待發(fa)送的通(tong)知，并將待發(fa)送的通(tong)知消息按照發(fa)送時(shi)間正(zheng)序(xu)(xu)排(pai)序(xu)(xu)；

17、步驟2.2：依次(ci)消(xiao)費延時通(tong)知隊列，線程(cheng)等(deng)待(dai)，直到當(dang)前時間等(deng)于通(tong)知消(xiao)息的發送(song)時間時，將(jiang)待(dai)發送(song)的消(xiao)息發送(song)到補(bu)發隊列；

18、步驟2.3：消費補(bu)發隊列，將通知(zhi)次(ci)(ci)數(shu)加(jia)1，判(pan)斷失敗重發次(ci)(ci)數(shu)是否大(da)(da)于(yu)設置的默認(ren)最大(da)(da)重試(shi)次(ci)(ci)數(shu)；如(ru)果重試(shi)次(ci)(ci)數(shu)超過最大(da)(da)重試(shi)次(ci)(ci)數(shu)，將事件存入(ru)終態表，在后(hou)臺(tai)管理(li)頁面展(zhan)示，等待人工處(chu)理(li)，不再發送該筆失敗的通知(zhi)；

19、步驟2.4：若通知(zhi)次數未達到(dao)最大(da)通知(zhi)次數，再次向(xiang)用戶(hu)發(fa)送交易成功通知(zhi)。

20、可選的(de)，在步驟2.4中：若發送(song)成功，事件(jian)存(cun)入終態表，通知(zhi)流程成功結(jie)束；當通知(zhi)失(shi)敗，由后臺配置的(de)下(xia)次(ci)通知(zhi)時(shi)(shi)間(jian)間(jian)隔數組計算出下(xia)次(ci)通知(zhi)時(shi)(shi)間(jian)，根據下(xia)次(ci)通知(zhi)時(shi)(shi)間(jian)時(shi)(shi)間(jian)間(jian)隔是否超過(guo)預設時(shi)(shi)間(jian)，進行以下(xia)處(chu)理：

21、根據當前(qian)的失敗次數，獲取到(dao)(dao)下次的發(fa)送時(shi)(shi)間(jian)(jian)(jian)間(jian)(jian)(jian)隔(ge)(ge)，若時(shi)(shi)間(jian)(jian)(jian)間(jian)(jian)(jian)隔(ge)(ge)在預設間(jian)(jian)(jian)隔(ge)(ge)以(yi)內時(shi)(shi)，發(fa)布kafka事件到(dao)(dao)延時(shi)(shi)隊列(lie)等待重(zhong)試；

22、若時間間隔在(zai)預設間隔以(yi)上，將事(shi)件封(feng)裝存入(ru)檢索數據(ju)庫表，等(deng)待(dai)定時任(ren)務喚(huan)醒重試。

23、根據本(ben)發(fa)明的第二方面，提(ti)供一種基于遞(di)增(zeng)定時補償異(yi)步通(tong)知支付(fu)結果的系統(tong)，包(bao)括：

24、業務模(mo)塊，用于在(zai)e賬通(tong)交(jiao)易模(mo)塊收(shou)到(dao)核心支付(fu)平(ping)臺的訂單支付(fu)結果后，封裝并發布事(shi)件通(tong)知(zhi)消息讓所述訂單支付(fu)結果進(jin)入通(tong)知(zhi)流程；

25、消(xiao)(xiao)息(xi)通知(zhi)模塊(kuai)，用于在e賬通交(jiao)易子模塊(kuai)收到通知(zhi)消(xiao)(xiao)息(xi)后，對平臺商戶進(jin)行首次(ci)通知(zhi)處理；其中，在通知(zhi)消(xiao)(xiao)息(xi)發送(song)前，設(she)置失敗(bai)最大(da)次(ci)數、每次(ci)發送(song)的時間間隔和通知(zhi)次(ci)數；如果(guo)首次(ci)通知(zhi)發送(song)成功(gong)，流程結束；如果(guo)首次(ci)通知(zhi)失敗(bai)，則進(jin)入到消(xiao)(xiao)息(xi)通知(zhi)的補發處理階段；

26、后臺管理模塊，用于定時(shi)任(ren)務檢索數據(ju)庫(ku)表，查找待補發(fa)的(de)通知消息，并發(fa)送(song)到(dao)延時(shi)處理隊列進行(xing)補發(fa)處理；直到(dao)補發(fa)成功或者(zhe)補發(fa)失敗次數達到(dao)上限，進行(xing)人工介入。

27、根據本發明的(de)第三方(fang)面，提供(gong)了一種(zhong)電子設備，包括存(cun)(cun)儲(chu)器(qi)、處理器(qi)，所述(shu)處理器(qi)用于執行存(cun)(cun)儲(chu)器(qi)中存(cun)(cun)儲(chu)的(de)計(ji)算機程序時(shi)實現上述(shu)所述(shu)的(de)一種(zhong)基于遞增定時(shi)補償(chang)異步通知支付結果的(de)方(fang)法的(de)步驟。

28、本(ben)發(fa)明的技(ji)術效(xiao)果和優(you)點：

29、本(ben)發(fa)明提供的(de)一種基于遞增定時補償異(yi)步通(tong)(tong)知(zhi)(zhi)支付結(jie)果(guo)的(de)方法及系(xi)統，基于kafka異(yi)步通(tong)(tong)知(zhi)(zhi)，采用多種topic事件(jian)隔離處理(li)機制，如(ru)event_topic事件(jian)只處理(li)trade交易模塊首次發(fa)送(song)的(de)通(tong)(tong)知(zhi)(zhi)事件(jian)；delayed_event_topic事件(jian)只用來處理(li)即將發(fa)送(song)的(de)消息的(de)等(deng)待(dai)；retry_event_topic事件(jian)只處理(li)首次失(shi)敗后，再次發(fa)送(song)通(tong)(tong)知(zhi)(zhi)的(de)事件(jian)。這樣(yang)新的(de)交易通(tong)(tong)知(zhi)(zhi)不(bu)會因為老的(de)不(bu)通(tong)(tong)過的(de)通(tong)(tong)知(zhi)(zhi)阻塞。

30、本發(fa)明(ming)采用線(xian)程等(deng)待(dai)和定時任務(wu)兩種(zhong)方式聯(lian)合處理通知事件(jian)，線(xian)程等(deng)待(dai)可以精確(que)的(de)發(fa)布下(xia)次通知事件(jian)距(ju)離當(dang)前時間(jian)1分鐘(zhong)內的(de)事件(jian)。定時任務(wu)處理下(xia)次通知事件(jian)距(ju)離當(dang)前時間(jian)1分鐘(zhong)以上(shang)的(de)事件(jian)，避免線(xian)程長(chang)時間(jian)等(deng)待(dai)，浪費系統資(zi)源。

31、本(ben)發明(ming)(ming)的其它特征和優(you)點將在(zai)隨后的說明(ming)(ming)書(shu)(shu)中(zhong)(zhong)闡述(shu)，并且，部分地從說明(ming)(ming)書(shu)(shu)中(zhong)(zhong)變(bian)得顯而易見，或(huo)者通過(guo)實施本(ben)發明(ming)(ming)而了解。本(ben)發明(ming)(ming)的目(mu)的和其他優(you)點可(ke)通過(guo)在(zai)說明(ming)(ming)書(shu)(shu)、權利要求書(shu)(shu)以及附圖中(zhong)(zhong)所指出(chu)的結構來實現和獲(huo)得。

技術特征：

1.一種基于遞增定(ding)時補(bu)償異步通知支(zhi)付(fu)結果的方法，其特征(zheng)在于，所述方法包括以下步驟：

2.根(gen)據權(quan)利(li)要求1所述的一種基于遞(di)增定時補償異步(bu)通知(zhi)支付(fu)(fu)結(jie)果的方法(fa)，其特征在(zai)于，所述e賬(zhang)通交易模(mo)塊(kuai)收到核心支付(fu)(fu)平(ping)臺的訂單(dan)最終結(jie)果，封裝并發布kafka事件event_topic。

3.根據權利要求2所述(shu)的(de)一種基于遞增定(ding)時(shi)補償異步通(tong)知支(zhi)付(fu)(fu)結果(guo)的(de)方法，其特征在于，所述(shu)e賬通(tong)交易模塊(kuai)收到核心支(zhi)付(fu)(fu)平(ping)臺的(de)訂單支(zhi)付(fu)(fu)結果(guo)后，封裝并發(fa)布事件通(tong)知消息讓所述(shu)訂單支(zhi)付(fu)(fu)結果(guo)進入通(tong)知流(liu)程包括(kuo)：

4.根據權利要求3所述的一種基于(yu)遞增定時補償(chang)異步通知(zhi)支付結(jie)果的方(fang)法，其(qi)特征在于(yu)，所述最大(da)失敗(bai)發(fa)送(song)次數為對(dui)應(ying)的11次，其(qi)中，首次發(fa)送(song)為1次。

5.根據(ju)權利要求3所(suo)述(shu)的一種基于(yu)遞增定時補償異(yi)步(bu)通知支付結(jie)果的方法，其特征(zheng)在于(yu)，所(suo)述(shu)每次發送時間(jian)間(jian)隔設(she)置(zhi)為以下(xia)任一種：

6.根據權利(li)要求1所(suo)述的(de)一種基(ji)于遞增(zeng)定時補償(chang)異步通知(zhi)支付結果的(de)方法，其特(te)征在于，所(suo)述e賬通交易子模塊webhook收到kafka事件event_topic后，對平臺商戶進行首次通知(zhi)處理。

7.根(gen)據(ju)權利要求1所述的一種(zhong)基(ji)于遞增定(ding)時(shi)補(bu)償異步通知支付結(jie)果的方法，其特征在于，所述定(ding)時(shi)任務檢索數(shu)據(ju)庫表，查找(zhao)待補(bu)發的通知消息，并發送到延時(shi)處理隊列進行補(bu)發處理；直到補(bu)發成(cheng)功或者補(bu)發失(shi)敗次數(shu)達到上限，進行人工介入包(bao)括：

8.根據(ju)權利要求7所述的(de)一種基于遞增定時(shi)補償異步(bu)通(tong)知(zhi)(zhi)支(zhi)付結果的(de)方(fang)法，其特征在(zai)于，在(zai)步(bu)驟2.4中：若發送成(cheng)(cheng)功，事件存(cun)入終態表，通(tong)知(zhi)(zhi)流(liu)程成(cheng)(cheng)功結束(shu)；當通(tong)知(zhi)(zhi)失敗，由后臺配置的(de)下次通(tong)知(zhi)(zhi)時(shi)間(jian)間(jian)隔(ge)數組(zu)計算出下次通(tong)知(zhi)(zhi)時(shi)間(jian)，根據(ju)下次通(tong)知(zhi)(zhi)時(shi)間(jian)時(shi)間(jian)間(jian)隔(ge)是否(fou)超(chao)過預設(she)時(shi)間(jian)，進行(xing)以下處理(li)：

9.一種基于遞增定時補償異步通知支付(fu)結(jie)果的系統，其特(te)征(zheng)在于，包括：

10.一種電子設備，其(qi)特征在于，包(bao)括(kuo)存(cun)儲(chu)器、處理器，所述處理器用于執行存(cun)儲(chu)器中(zhong)存(cun)儲(chu)的(de)(de)計算機程序時實現(xian)如權利要求1至8任一項所述的(de)(de)一種基于遞增定時補償異步通知支付結果的(de)(de)方(fang)法(fa)。

技術總結
本發明提供一種基于遞增定時補償異步通知支付結果的方法及系統，所述方法包括：E賬通交易模塊收到核心支付平臺的訂單最終結果后，封裝并發送通知消息；E賬通交易子模塊收到通知消息后，對平臺商戶進行首次通知處理；其中，在通知消息發送前，設置失敗最大次數、每次發送的時間間隔和通知次數；如果首次通知發送成功，流程結束；如果首次通知失敗，則進入到消息通知的補發處理階段；此時，定時任務檢索數據庫表，查找待補發的通知消息，并發送到延時處理隊列進行補發處理；直到補發成功或者補發失敗次數達到上限，進行人工介入。本發明提供一種基于遞增定時補償異步通知支付結果的技術方案，能夠按時準時的補償異步通知到商戶平臺交易結果。

技術研發人員：曾令華,李耀,彭磊
受保護的技術使用者：武漢眾邦銀行股份有限公司
技術研發日：
技術公布日：2024/9/19