在效能測試過程中，經常會遇到因重複提交或重複生成導致事務失敗的問題，下面以下單重複的問題為例，對此類問題的定位和解決思路做一些總結。
效能測試場景為下單，效能測試過程中，事務失敗率過高，接近3：1；tps曲線上下波動較大。
1. 下單失敗的報錯均為訂單重複問題：此訂單已經存在，請不要重複提交
2. tps出現有規律的上下波動，如圖：
1. 檢查系統日誌檢視報錯原因：在日誌中找到因重複提交導致的定單號，通過檢查資料庫，發現此訂單已成功插入資料庫，因此重複提交必然會報錯。
3. 檢查系統訂單生成規則，是否會存在大量提交的時候系統生成訂單重複的問題：經檢查，系統訂單生成規則為2位固定字首+yymmddhhmm+3位長度seq數值。
很明顯，問題就出在訂單生成規則這裡，同一分鐘內，僅支援1000筆訂單，當壓測時大量下單時，同一分鐘內只要有超過1000筆訂單，餘下的下單都會出現重複報錯。通過檢查tps曲線圖，也基本符合一分鐘就下降一次的規律。系統下單規則設計之初未考慮到大併發的場景，1分鐘僅支援1000筆訂單，即tps大於1000/60~16.7。
通過修改訂單生成規則，去掉yymmddhhmm的限制（方法有多種，這裡只是其中一種），事務失敗率和tps曲線波動的問題都得到了解決。
總的來講，對於這類重複類的問題，我個人認為的定位思路為：
1. 檢查系統日誌檢視報錯原因
2. 檢查效能測試指令碼中是否有導致重複問題的相關引數，找到並檢查引數設定
3. 檢查系統內部生成規則，是否會導致大併發的時候出現重複問題
以後有新的總結，希望我也能一併放一起，方便交流學習。
sysbench小檔案測試問題解決
想測試指定檔案個數的小檔案是比如217k，1w個檔案，進行到100多時會報，反覆嘗試都如此 fatal too large position discovered in request 後面想了估計跟block size有關，估計每個檔案的大小必須是blocksize的整數倍才行。嘗試了一下，果然如...
興業銀行支付介面測試問題解決
一直在測試興業銀行的支付介面，在支付成功之後，返回 頁面的時候，居然不能顯示 支付成功 頁面，提示無法開啟頁面，乙個404的錯誤。檢查來檢查去，也跟蹤了一堆 ctl.payment.php中的result 方法 if payment member id payment member id this ...
興業銀行支付介面測試問題解決
一直在測試興業銀行的支付介面，在支付成功之後，返回 頁面的時候，居然不能顯示 支付成功 頁面，提示無法開啟頁面，乙個404的錯誤。檢查來檢查去，也跟蹤了一堆 ctl.payment.php中的result 方法 if payment member id payment member id this ...