1. 創(chuàng)建一個(gè)自定義進(jìn)程，進(jìn)程啟動(dòng)加載一個(gè)timer，timer定時(shí)收集一部分超過閾值的未完結(jié)訂單，然后主動(dòng)請(qǐng)求微信訂單狀態(tài)；
2. 創(chuàng)建webhook回調(diào)地址，用于接收異步通知消息；

這叫什么輪詢，這不就是定時(shí)器定時(shí)調(diào)微信接口么，開個(gè)定時(shí)器調(diào)就完事了

我是這樣干的，創(chuàng)建一個(gè)2秒定時(shí)器，下單時(shí)將訂單信息存儲(chǔ)在緩存中，在定時(shí)器里從緩存里讀取訂單信息向微信接口請(qǐng)求狀態(tài)再更新。

為啥不是在前端處理定時(shí)呢，我們最近有個(gè)購(gòu)票的業(yè)務(wù)，需要h5下單成功后去票務(wù)系統(tǒng)下單，但是靠微信異步通知再去票務(wù)系統(tǒng)下單會(huì)出現(xiàn)延遲問題 還有就是用戶h5下單成功了 票務(wù)可能會(huì)出票失敗，基于這個(gè)問題我們解決的方式是
1.前端用戶支付成功后，開啟定時(shí)請(qǐng)求后臺(tái)訂單支付結(jié)果查詢接口
2.查詢支付成功后對(duì)票務(wù)系統(tǒng)下單，票務(wù)系統(tǒng)下單成功，h5訂單下單才算成功，票務(wù)系統(tǒng)失敗，對(duì)該筆訂單自動(dòng)執(zhí)行退款，退款失敗提醒客戶聯(lián)系平臺(tái)（一般不會(huì)出現(xiàn)這種情況）

做完這個(gè)小系統(tǒng)后 我思索了很久之前做過的支付，其實(shí)都存在支付問題，單純的靠異步通知是解決不了訂單的狀態(tài)更新問題的，尤其前端要求下單成功后進(jìn)入訂單詳情的場(chǎng)景，回調(diào)稍微延遲下，按我以前的做法都會(huì)面臨客戶明明支付成功了，進(jìn)入訂單卻是待支付

微信下單，后端只是生成前端拉起支付的數(shù)據(jù)。若想后端獲取該筆交易的支付狀態(tài)，有以下方案：

1. 依據(jù)微信的支付通知回調(diào)。微信支付通知回調(diào)，會(huì)在用戶成功支付后，下發(fā)給統(tǒng)一下單時(shí)配置的通知回調(diào)url；若業(yè)務(wù)服務(wù)器未按照微信官方約定返回給微信，微信會(huì)按照策略繼續(xù)下發(fā)。
2. 使用定時(shí)器查詢訂單。使用定時(shí)器定時(shí)批量查詢未完結(jié)訂單，然后請(qǐng)求微信接口查詢訂單的支付狀態(tài)。這種方式在訂單量大的情況下會(huì)導(dǎo)致訂單狀態(tài)更新慢的問題。
3. 使用消息中間件。在每次下單時(shí)，將訂單信息下發(fā)給消息中間件的生產(chǎn)者，在消息中間件的消費(fèi)者里請(qǐng)求微信接口查詢訂單的支付狀態(tài)并做更新。這里可設(shè)置消費(fèi)者的數(shù)量及該筆交易消費(fèi)次數(shù)和延時(shí)消費(fèi)時(shí)間等，若某一筆交易在處理 M次*N秒 后仍然時(shí)未支付，則可認(rèn)為該交易用戶未支付。
4. 開發(fā)微信支付中臺(tái)服務(wù)。將微信支付相關(guān)接口封裝，在中臺(tái)里開發(fā)服務(wù)接管微信的通知回調(diào)并做記錄，需要保證中臺(tái)服務(wù)的安全性，穩(wěn)定性等。后續(xù)所有的支付業(yè)務(wù)和中臺(tái)對(duì)接。
5. 前端輪詢。該 "支付結(jié)果查詢中" 的展示是僅面向用戶的，輪訓(xùn)查詢本系統(tǒng)的訂單狀態(tài)即可。
   目前，我們公司的做法是：1+3+4+5。

其實(shí)也很簡(jiǎn)單了
1、用戶下單創(chuàng)建支付訂單時(shí)，把支付信息也一起放到隊(duì)列去
2、在創(chuàng)建一個(gè)時(shí)間任務(wù)去查詢隊(duì)列（消費(fèi)），查詢是否已經(jīng)支付成功
3、查詢用戶未支付時(shí)，再放到隊(duì)列去
4、設(shè)置一個(gè)閥值，輪詢N次還是未支付情況下基本上用戶是不會(huì)去支付了，所以可以關(guān)閉此條消費(fèi)記錄了（創(chuàng)建微信支付時(shí)，有一個(gè)支付超時(shí)，可以聯(lián)動(dòng)起來）

加個(gè)延遲隊(duì)列，下單后塞進(jìn)去5分鐘后查看這條訂單是否已經(jīng)支付了，沒支付就查一次微信判斷就可以了吧