<!------------處理邏輯-------------------------------------------->

同步：指發出一個請求後，需要等待返回，才能進行下一個請求觸發，有個等待的過程

異步：指發出一個請求後，不需要等待返回，隨時可以觸發下一個請求，不需要等待

區別：一個需要等待，一個不需要等待，在部分情況下、有的項目開發中都會優先選擇不需要等待的異步交互方式。

哪些情況建議使用同步交互呢？比如銀行的轉賬系統，對數據庫的保存操作等等，都會使用同步交互操作，其余情況都優先使用異步交互。

換種方式也可以這樣理解：

1.用戶（買家）支付完成後，電商平臺需要實時的給用戶一個通知，如支付已經處理等待訂單確認。

2.電商平臺，這塊就需要考慮系統技術方面的各個環節，考慮應對復雜多變的並發用戶量、業務、流量、網絡環境等因素，我們需要把可以異步化的任務進行分離，算是保障系統可造性、可用性的一個重要的點。

3.電商網站每秒鐘承接1w、5w、10W交易量甚至更高的時候，實時處理這些請求挑戰很大，但如果把這些請求分離業務狀態實現異步化，放入消息系統、異步準實時環境，進而整體網站的復雜度降低，這就是同步和異步通知存在的意義。
4.第三方支付公司接入文檔上都會有以異步通知為準的約束。
5.其實除了通知這塊，還有一塊會被忽略，就是支付查詢類接口，這一塊的作用如果用好了，對系統業務層會省很多人力

我們測試一般當完成一個支付請求被發送到支付渠道方，支付渠道會很快返回一個結果。但是這個結果，只是告訴你調用成功了，不是扣款成功，這叫同步調用。很多人拿這個結果當作支付成功了，那就會被坑死，結果就是支付成功率特別高，伴隨著一堆無法解釋的壞賬率，測試人員尤其要註意測試數據的篡改：金額，同步返回結果，訂單號等。

同步請求參數裏面會有一個回調地址，這個地址是支付渠道在扣款成功後調用的，這叫異步調用。一般同步接口僅檢查參數是否正確，簽名是否無誤等。異步接口才告訴你扣款結果。一般異步接口有5秒以內的延遲。調用不成功會重試。有時候是這邊成功了，但支付渠道側沒收到返回，於是會繼續調。當天的支付到第二天還在被異步調用也都是正常的。這也是開發人員需要特別註意的地方，不要當做重復支付。測試人員也要對重復回調進行測試，應只有一次有效。這還不是最坑的，一般支付渠道側，只有支付成功了才通知你。要是支付失敗了，壓根兒都不告訴你。 另一方面，如何老收不到異步結果呢？那就得查查了。同步結果不可靠，異步調用不可靠，那怎麽確定支付結果？最終的殺招就是查單了，反查，一般支付渠道側都會提供反查接口，定時獲取DB中待支付的訂單調用支付渠道側的反查接口，最終把支付渠道側扣款成功的訂單完成掉。

支付同步和異步