問題描述

考慮到用線程或者定時任務，不知道有沒有人做過這個

問題解答

類似的異步處理通知接口基本上都需要做這種處理的，因為異步的回調(diào)通知總會因為網(wǎng)絡(luò)或者處理延時造成沒有進行回調(diào)通知。具體的做法就是首先在調(diào)用異步接口前，需要先生成一個待處理的訂單，然后調(diào)用支付寶接口進行支付，支付完成后正常情況支付寶會主動請求你的回調(diào)接口，如果沒有請求的話，你的訂單狀態(tài)將會保持待處理的狀態(tài)。然后再做一個定時任務，每隔一段時間，查詢一下待處理的訂單，根據(jù)支付寶返回的訂單狀態(tài)來更新對應的狀態(tài)就可以了，需要注意的是控制訂單查詢的時間，不建議把所有的訂單找出來去更新，根據(jù)你的數(shù)據(jù)量來處理，一般的話遠程請求支付寶接口同步處理的話也比較耗時，未處理的訂單太多了就根本處理不過來，建議的做法是直接把查詢請求發(fā)送到MQ上，然后根據(jù)數(shù)據(jù)量大小開多個消費者服務，來處理查詢請求。另外還有一種簡單粗暴的方式也可以，直接對待處理的訂單不做處理，但是給用戶提供一個功能，讓用戶主動發(fā)起請求，用戶點擊重試按鈕后直接調(diào)用支付寶查詢接口查詢訂單支付狀態(tài)。

訂單的幾個狀態(tài)： 待支付，已支付到支付寶，支付寶支付完成。主要應對的是：已支付到支付寶。考慮的幾個點： 實時性，冪等性

實時性：根據(jù)你具體的業(yè)務場景，單進程多線程，多進程處理。多進程的話需要分區(qū)段處理數(shù)據(jù)，保證數(shù)據(jù)的不重復冪等：每個訂單必須有唯一的標識，每個環(huán)節(jié)處理的時候，保證這個訂單已經(jīng)被處理過了。