1,應用場景
同步：所謂同步，就是在發出一個功能調用時，在沒有得到結果之前，該調用就不返回
異步：異步概念和同步相對。當一個異步過程調用發出后，調用者不能立刻得到結果。
實際處理這個調用的部件在完成后，通過狀態、通知和回調來通知調用者。
應用場景：交易結果異步通知、渠道處理異步通知、賬單信息異步通知、異步事務觸發、掉單查詢異步處理等
2，同步異步防資損的checklist
【1】同步調用返回
同步請求信息校驗、組裝下游請求信息、響應信息處理、同步向上返回
1.1 說明
同步調用返回處理主要關於按照接口文檔定義，同步的請求信息的組裝和響應信息的處理。重點關注同步請求信息的組裝和信息的校驗、響應信息中敏感信息處理和引發的相關后續事務，處理不當都會引發資損。
1,2 資損原因
同步請求信息校驗不完善，如金額沒有校驗，系統與系統之間的金額存儲單位不一致，導致后面交易金額錯誤，對賬信息未傳正確導致出現長短款
組裝下游請求信息有誤，如金額明細與總單金額不一致，敏感必填字段未控制並下游異常失敗未做回退機制
響應信息的敏感信息未處理
引發的后續事務，處理不當，如狀態、響應碼、對賬信息等和對應的觸發事件，如該沖正的未沖正，不該沖正的沖正
1.3 測試方法
根據接口文檔的請求和響應，覆蓋各類的必填項、類型、長度和業務性場景
重點關注各類返回的后續動作
注意上下聯調，保證一致性
【2】同步調用超時
處理中：掉單/重試、降級、失敗
2.1 說明
同步請求時下游在規定時間內無返回，系統引發的才超時處理，一般記處理中、降級或失敗。重點關注超時后狀態的記錄和后續引發的事務。
記處理中，需要引發掉單、重試或沖正等事務，一般用於交易渠道等
失敗需要引發回退，一般對時間要求很高的功能，如收單、pos等
降級，即超時后繼續往下調用其他系統，一般用於非核心鏈路，可以不調它，不響應主要功能，如決策、風控等、
2.2 資損原因
超時后未處理好正確的狀態和后續引發的事務。如超時簡單的當做失敗沒有后續退款事務，掉單將無此交易當做失敗（剛超時的記錄進行掉單處理很容易返回無此交易）、重試沒做好冪等控制、沖正不該沖正的沖正掉等。
2.3 測試方法
采用數據庫鎖表的操作，讓下游遲遲未返回
2.4 樣例
超時掉單處理時，下游系統數據庫遲遲未處理完，未將記錄插入渠道信息，當掉單時下游返回無此交易，交易處理成失敗，等數據庫處理完后，渠道處理為成功，引發用戶扣了錢但系統認為沒扣的情況，導致用戶資損。
【3】同步調用失敗
同步失敗記失敗做事務回退、同步失敗落人工、同步失敗做降級處理
3.1 說明
同步調用失敗是指調用時出現異常，如系統掛了或報異常類錯誤等，不是有返回並返回信息狀態為失敗的情況。注重同步調用失敗系統狀態信息等的記錄和相關引發的后續事務。
同步失敗后一般處理方法有如下幾類：
同步失敗記失敗做事務回退，如消費交易失敗引發沖正
同步失敗落人工，如出金交易等，失敗走人工調賬或線下處理
同步失敗做降級處理（不影響核心功能），繼續往下執行功能，如調決策、風控等
3.2 資損原因
同步調用失敗信息的記錄，如未做任何異常捕獲、未引發沖正等
3.3 測試方法
調用系統未啟動
調用系統dubbo禁掉
請求地址有配置項，修改成錯誤的請求地址
【4】同步重復調用
重復、並發（冪等控制）
4.1 說明
同步重復調用是指一個請求重復調用兩次及以上，重點關注冪等，關注重復調用的控制和並發時是否會被擊穿。
4.2 資損原因
如一個交易單同時支付兩次成功，出現用戶扣了兩次錢，交易單成功一個，發貨一次；
如一個人每天領積分，今天領用再次領分，如果出現重復領分，導致資損
4.3 測試方法
重復調用需要並發測試
【5】異步處理
發送者組裝的內容、形式、正確解析和消費
5.1 說明
異步處理，主要根據上下游異步消息交互定義，正確的發送消息和接收消息。重點關注發送者組裝的內容、形式和接收者正確解析和消費
5.2 資損原因
如異步交易信息發送后消費失敗，用戶資金已經扣除，業務狀態遲遲未成功，商戶未發后，導致用戶資損。
5.3 測試方法
上下游聯調
模擬發Q
【6】異步重復發送
重復、並發（冪等）
6.1 說明
異步重復發送消息是指發送消息時，一樣的消息名稱一種的消息內容重復發送，重點關注冪等，關注重復發送消息時的控制和並發是否會被擊穿
6.2 資損原因
如渠道扣款后重復發送通知成功消息給上游，上游未做防重控制，導致該渠道扣款以后的指令重復執行或線程錯亂等。
如份額異步通知扣款，導致重復加減額。
6.3 測試方法
並發測試、模擬發Q
【7】異步發送順序
同種Q，不同Q（避免重復處理）
7.1 說明
異步發送順序是消息的先后，可以不同消息名稱也可以同一個消息名稱，關注消息發送后“后發先至”的處理情況。
7.2 資源原因
如消息發出后，前一個消息由於消息積累未及時消費，后發的消息到了未做處理或做了處理后先發的消息到時的重復處理。
7.3 測試方法
模擬發Q
7.4 樣例
交易信息通知功能，當交易先進行中，發上游告知信息通知為進行中；當交易成功后，發上游告知信息停止為成功。其中當出現第一個進行中的消息后到，導致先處理成功后在處理成進行中，用戶已經扣款，業務狀態為進行中，商戶未發貨，出現用戶資損。
【8】異步消息類型用錯
queue、topic
8.1 說明
異步消息類型目前分Q和同topic，一般Q為一對一，topic為一對多。重點關注一個對多個其他系統和一個系統的多個服務器。
8.2 資損原因
當出現一個渠道結果通知信息采用了topic的方式並且同時讓一個系統的多台服務器處理了，系統又未做相關冪等控制，導致資損。
8.3 測試方法
MQ平台內核對Q配置類型
多台服務器場景測試
【9】異步比同步快
異步處理、同步處理（避免重復處理）
9.1 說明
當同步請求下游系統后，同步響應還未處理完成，下游異步消息已經返回。重點關注異步消息返回后的系統處理情況。
9.2 資損原因
當同步請求下游系統后，同步響應還未處理完成，下游異步消息已經返回，導致異步消息未處理或異步消息處理后同步響應返回后重復處理。
9.3 測試方法
人工模擬發Q，控制同步響應延遲，如鎖數據庫，開發代碼改動等
9.4 樣例
如消費-銀行卡支付，當銀行扣款同步請求返回進行中，其中出現下游異步比同步快時，系統先接受到成功消息后引發后續事務，下游又同步返回時又引發后續事務，導致后續事務多次執行引發資損。
【10】同步異步都返回
10.1 說明
同步異步都返回是指同樣的信息同步異步都返回，需要重點關注上下游的約定。
10.2 資損原因
如未按照約定執行，如同步返回成功后引發后續事務，異步返回成功又引發后續事務，導致多次重復執行事務。一般按照約定，如約定為都按照異步消息處理，那就不處理同步請求信息；或約定為當同步返回成功后下游不需要再次返回異步消息等。
10.3 測試方法
同步成功后人工模擬發Q
10.4 樣例
上下游預定同步返回成功后下游不再返回異步消息，但當下游異常時未按約定執行，導致上游系統出現重復執行或線程錯亂，導致資損。
【11】其他
如何控制冪等
1，悲觀鎖
並發情況下，當第一條查詢時，就把表加鎖，等事務完成之后，再釋放
缺點：性能不好
2，樂觀鎖
並發情況下，每次執行事務時，都查詢一下，是否只存在一條，如果不是則回滾
缺陷：回滾事務太多，容易出錯
3，去重表
並發情況下，每次執行時，都先在去重表中新增一條記錄，永遠只會執行一次