BUG作者：四摧
BUG標題：
事務處理過程中數據加鎖不合理，導致同一數據源在交易過程中被其他交易改變
BUG影響：
1688極速到賬、賬期支付等場景下併發下單失敗或金額佔用不準確現象，造成擔保方金額虧損
BUG發現過程：
1）前期參與開發代碼review，梳理1688極速到賬、賬期支付等場景事務處理過程和鎖使用機制，識別代碼風險點；
2）測試設計階段：針對性地設計各種交易複雜場景高併發壓測；
3）測試過程中：編寫數據校驗腳本，在上億條日誌中檢查每筆交易訂單正確性，並找到必現條件；
原因爲：交易過程中要用到的數據源被其他買家與該賣家交易時改變，導致失敗卻沒有進行回滾，必現條件如下圖所示：
BUG解決方法：
在數據源被鎖住的代碼裏再次添加查詢剩餘額度代碼後再進行金額佔用，並保證失敗後能進行數據回滾（注：第一次查詢剩餘額度目的是查詢需要用到幾種授信源和各自的剩餘金額進行數據鎖定，開發認爲在查詢和數據鎖定之間時間極短不可能發生改變，故在鎖內未加入再次查詢節省性能開銷），同時在迴歸過程中評估修改影響，注意鎖內操作變多帶來的接口性能下降問題，經測試確實下降3MS左右幸好滿足預期。
GBA傳承
1、針對數據庫鎖測試時，一定要考慮併發測試場景，並確保查詢和使用數據源都在鎖內進行，避免數據不準確；
2、性能壓測過程中除了觀察接口調用返回正確性，還需要觀察產生的數據是否完全和預期相符，數據量大時建議用腳本或者編寫小工具進行校驗，在上億條日誌中不要放過任何一條可疑日誌。
個人感受：
1、事務處理和數據鎖相關測試，需要介入代碼review，並理清各種約束條件和觸發場景設計壓測用例；
2、需求評估階段單純的認爲接口壓測僅需要把各種接口串聯在一起進行併發測試，只需要觀察接口返回正確性就OK，差點疏忽了複雜場景下接口返回是成功了但數據可能不一致的場景；
3、涉及金額的測試，出現概率就算再小也是大事，需要多留一份心。