考慮到用線程或者定時任務，不知道有沒有人做過這個
2
0
0
光陰似箭催人老，日月如移越少年。
類似的非同步處理通知介面基本上都需要做這種處理的，因為非同步的回呼通知總是會因為網(wǎng)路或處理延遲造成沒有進行回調通知。
具體的做法就是首先在調用異步接口前，需要先生成一個待處理的訂單，然後調用支付寶接口進行支付，支付完成後正常情況支付寶會主動請求你的回調接口，如果沒有請求的話，你的訂單狀態(tài)將會保持待處理的狀態(tài)。
然後再做一個定時任務，每隔一段時間，查詢一下待處理的訂單，根據(jù)支付寶返回的訂單狀態(tài)來更新對應的狀態(tài)就可以了，需要注意的是控制訂單查詢的時間，不建議把所有的訂單找出來去更新，根據(jù)你的數(shù)據(jù)量來處理，一般的話遠程請求支付寶接口同步處理的話也比較耗時，未處理的訂單太多了就根本處理不過來，建議的做法是直接把查詢請求發(fā)送到MQ上，然後根據(jù)資料量大小開立多個消費者服務，來處理查詢請求。
另外還有一種簡單粗暴的方式也可以，直接對待處理的訂單不做處理??，但是給用戶提供一個功能，讓用戶主動發(fā)起請求，用戶點擊重試按鈕後直接調用支付寶查詢接口查詢訂單支付狀態(tài)。
訂單的幾個狀態(tài)： 待支付，已支付到支付寶，支付寶支付完成。
主要應對的是：已支付到支付寶。
考慮的幾個點： 即時性，冪等性
實時性：根據(jù)你具體的業(yè)務場景，單進程多線程，多進程處理。多進程的話需要分區(qū)段處理數(shù)據(jù)，保證數(shù)據(jù)的不重複
冪等：每個訂單必須有唯一的標識，每個環(huán)節(jié)處理的時候，保證這個訂單已經(jīng)被處理過了。
