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