支付業務，測試遇到請求超時怎么處理？查看是否是網絡原因；fiddler抓包查看原因；
支付業務流程測試，參考：https://www.jianshu.com/p/9e3f4e66a273
同步用於即時通知支付完成（立即通知）；
異步用於防止信息漏發漏收（稍后通知）；
冪等性，其實就是數據一致性和事務完整性；
數學上的定義：f(f(x))=f(x)。x被函數f作用一次或作用無限次的結果是一樣的；
某個函數或者某個接口使用相同參數調用一次或者無限次，其造成的后果是一致的；
在實際應用中一般針對接口進行冪等性設計。例如：
1.前端重復提交選中的數據，后台應該只產生對應本次提交的一個響應結果；
2.用戶發起一筆付款請求，應該只扣除用戶賬號一次錢，即使遇到網絡重發或系統bug重發時，也只扣除一次錢；
3.創建業務訂單時，一次業務請求只能創建一個訂單；
如果相關接口不做冪等性。可能會造成很嚴重的后果，例如：
1.前端重復提交選中的數據，后台可能產生多個響應結果，數據不能保持一致性；
2.用戶發起一筆付款請求，如果遇到網絡超時，同一個請求重復發送多次，可能造成用戶賬號多次扣款；
3.創建業務訂單時，一次業務請求可能會產生多個訂單；
如何保證冪等性？
冪等性需要通過唯一的業務單號來保證。也就是說相同的業務單號，認為是同一筆業務。使用這個唯一的業務單號來確保，后面多次的相同的業務單號的處理邏輯和執行效果是一致的。
下面以支付為力，在不考慮並發的情況下，實現冪等很簡單：1）先查詢一下訂單是否已經支付過；2）如果已經支付過，則返回支付成功；如果沒有支付，進行支付流程，修改訂單狀態為'已支付'.
防重復提交策略
高並發下會出現下面的情況：第二次請求在第一次請求第2）步訂單狀態還沒有修改為‘已支付狀態’的情況下到來。既然得出了這個結論，余下的問題也就變得簡單；把查詢和變更狀態操作加鎖，將並行操作改為串行操作；
樂觀鎖：
如果只是更新已有的數據，沒有必要對業務進行加鎖，設計表結構時使用樂觀鎖，一般通過version來做樂觀鎖，這樣既能保證執行效率，又能保證冪等。例如：update tab1 set col1=1，version=version+1 where version=#version#
分布式鎖
如redis。訂單發起支付請求，支付系統會去redis緩存中查詢是否存在該訂單號，若存在則給出提示；若不存在，則在redis中增加該訂單號，執行結束后（成功/失敗），刪除該訂單號；
參考：https://www.sohu.com/a/239759335_741445