客戶端超時 相關 同時 連接 其他 ria tex 結轉 ros

情景一：客戶端超時時間（CT）小於服務端超時時間（ST）。【調整時間大小】
當客戶端調用服務端向數據庫發起請求時，假如是個大數據量提交，假如客戶端超時時間為10s，服務端超時時間為15s當提交等待時間為12s時，客戶端已經返回錯誤，而服務端未超時。最後12s後服務端提交成功。而客戶端返回失敗。

情景二：1、分布式鎖超時時間小於業務超時時間【調整時間大小】2、數據庫裏相關字段沒有唯一索引【增加唯一冪等性驗證】

那麽如果線程A提交的數據出現問題（如大數據提交等），處於等待狀態，並獲得分布式鎖。而線程B、C...也來提交，由於分布式鎖，訪問被攔截。當分布式鎖超時時間結束時，線程Z剛好提交。如果數據庫缺少唯一性索引，此時線程A與線程Z可能同時提交成功。

情景三：1、分布式鎖超時時間小於業務超時時間【調整時間大小】2、業務有重試機制3、數據庫裏相關字段沒有唯一索引【增加唯一冪等性驗證】
（1）由於數據庫連接數被占滿，流水 1 創建的事務處於等待提交狀態。
（2）系統 A 發現交易失敗，重試次數不滿 8 次的，立即發起重試，觸發生成流水
2 的請求。
（3）5s 以內數據均被分布式鎖攔截，無法提交。
（4）經過 5s 後，系統 B 的分布式鎖失效，此時事務仍在等待未提交。
（5）6s 時，流水 2 成功越過數據庫查詢冪等校驗發起事務，此時流水 1 拿到數
據庫連接，流水 1 和 2 兩個事務同時提交。
（6）由於數據庫未做唯一索引，且支付受理模塊打穿下層冪等原則，生成 2 個
TXID，導致兩事務同時提交成功。
（7）收益結轉重復記賬，用戶多了一筆收入。

得出一個結論：分布式鎖在以下條件同時滿足的情況下並發控制會被打穿。（1）上層業務系統層面有重試機制。
（2）業務請求存在一定時間之後提交成功的情況，例如本例中第一次請求在事務
等待 6s 後獲得了數據庫鏈接，提交數據庫成功。
（3）下遊系統缺乏其他有效的冪等控制手段

分布式下引發的並發問題