知識星球（點選上方公眾號，可快速關註）
來源：等你歸去來 ，
www.cnblogs.com/yougewe/p/8975550.html
由於一次功能上線後，導致某資料量急劇下滑，給我們緊張的呢！排查過程也是個學習過程！拋開結果，方法論可供參考～
1. 確認問題的真實性？
被資料部門告知，某資料量下滑嚴重，當時即知道問題的嚴重性。且該問題是在我的功能上線後產生，第一反應就是，我程式碼哪裡寫錯了？ 但是，還得按流程來，透過各種維度資料對比請求量，實際落地量。確認問題！
其實該過程中，我們並沒有確認自己的資料量下滑。但是這也脫不了資料下滑的幹係。只能進行下一步！
2. 檢查程式碼，找有經驗的同學，對比原有功能差異點？
這個步驟其實，是有點盲目的感覺。因為第一步的排查並沒有找到足夠的證明說明問題出在我們，但是問題在於期間只有我們上過線，所以只能自我反省了。
不過幸好，這過程還真有用，果真發現了自己埋的一個坑，此坑確實會導致該資料量的下滑。趕緊修掉唄！
然後鬆了一口氣，以為搞好了。其實不然，資料量依然上不去。這就尷尬了！
我已經開始懷疑人生，難道程式碼沒發上去？難道線上和本地某個地方不一樣？測試環境反覆測試正確無誤。我真想直接把測試環境程式碼弄到線上去，哎，算了吧，很多東西是不會以人的意志為轉移的，咱們還是理性點！別謀出路吧！
3. 直接坐到dba旁邊去吧，讓我們隨時關註資料量？
自我排查已經救不了自己了，那就上dba那裡。麻煩幫我統計下上線後，資料量的變化，結果是沒多大差別。心想有可能是時間太短，看不出變化，等會兒再統計吧。依然沒有變化！我的神吶，定了鍋還在。
大的資料量不行，那我用自己的賬號來測試吧，操作完成後，觀察資料，發現有時有有時無！額，說不出啥了。
4. 本地除錯吧？
原本以為，是線上問題，緊急處理下就好了。然而事實卻超出了我的預料，將驗證直接交給線上，是對使用者的不負責，是對資料的不負責。咱們還是從本地做起吧。
本地除錯要走vpn，有點煩，但不管怎麼樣，還是跑起來了。沒問題啊！這尷尬了。
然後，引出下一個議題！
5. 線上環境配置與測試環境不一樣？
然後我們努力找出其中的不同點，哪怕是多了一個檔案，某個檔案的更改時間點不一致，我們都想去試一下！當然了，為了穩妥起見，我們還是不能直接線上上驗證的，除非有足夠的證據說明線上的配置是有問題的。當然我們最終並沒有找到這樣的證據，只是將線上的所有東西都搬到測試環境來驗證，結果是暢通無阻！
還有一個證明此路不通的理由，之前的配置跑得好好的東西，難道會自己壞掉？不可能吧。此路不通！
6. 實在不行了，只能改程式碼線上除錯？
除錯第一步，各自打日誌！把之前請求列印不全的地方，加上完整日誌，再發一版吧！有了日誌，就有證據，但是真的是急中生錯啊，日誌居然打得不對，將引數列印為了記憶體地址也真是夠了。
日誌改好後，測試唄，繼續用自己的賬號。還是一樣，有時能能進有時不能（監控手段為dba起一個臨時的kafka消費者，然後將資料拉出來看）！那咋整呢？
難道是有的機器壞了？分配到壞的機器上去的請求就失敗，分配到正確機器的上去的請求就正確。然後吭哧吭哧搞了半天的資料驗證，曾經以為這是方向，結果又被打回。
7. 不行咱們就抓包吧？
tcpdump，一個網路流抓包神器，lsof助攻一下。
抓包只是為了確認一個問題，客戶機器有傳送請求到服務端機器，網路流正常運轉！然後證明，客戶端機器有大量長連線到伺服器，資料流傳送接收正常（syn）。這至少說明瞭一點，客戶端是沒有問題的！那麼就還剩一個問題，那就是服務端出問題了！我們堅信，當然要有證據嘛。
同理，我們在服務端機器上進行反向抓包，然後抓到了來自客戶端的包，很流暢嘛！額。。。
8. 不行，沒有思路了，重啟機器吧？
不，我說的是重啟服務。最近不是有改動嘛，按理誰改動重啟誰。然而這是沒有用的，因為之前的幾次釋出早已重啟了n次。那咋整呢。只剩重啟服務端，kafka服務了唄，死馬當活馬醫吧！
重啟後，驗證唄。結果貌似還是發現有成功，有失敗！
9. 改非同步請求為同步請求？
又沒思路了，我不甘心吶，為啥測試環境好好的，到線上就不行了呢？再想想差別在哪裡？
得出的結論是，線上併發大，測試環境量無。然後發現這一塊程式碼是由非同步執行緒做的，會不會是這裡有問題？
不管了，改成同步請求試試吧。再來一版！
別說，改為同步後，雖然使用者請求基本都慢死了，但是發現kafka請求確實存在了。難道真的是因為這個，那我們也不能這麼改啊，使用者體驗是第一位的，為了這事改非同步為同步，咱得吃不了兜著走啊。改回來繼續其他的吧！
10. 再回測試環境，壓測併發？
改還原為非同步後，又回到當初有成功有失敗境地了。
既然懷疑線上高併發導致，那為什麼不在測試環境高併發壓測一下呢？用shell指令碼快速寫了一個迴圈請求指令碼，大量請求到kafka後，並無一絲異常，到此併發問題取消。（for，nohup a.sh > /dev/null 2&>1 &）n 次即模擬n個併發請求
11. 再來細細檢查程式碼吧？
都不知道查了幾遍了，但是還是要查啊，不然咋整呢，幾個人一起看程式碼唄！
然而這並沒有什麼卵用。
12. 拋開使用者行為，直接以命令列形式操作請求？
雖然使用者行為是最真實的驗證，但是也是比較麻煩的驗證。
我們就拋開各種中間環節，直接向kafka伺服器發起請求！
分兩種方式，1 用現在的程式碼去請求，2 用kafka自帶的請求方式請求。結果得到兩個不同的結果，用程式碼的方式請求的資料，沒有成功，用kafka自己的請求方式，則毫秒級響應。哎，這是讓我又懷疑程式碼？
13. 已走投無路，讓我們再看一眼資料吧？
真的是沒有思路了，只能再來看看資料，當打發時間了。
意外就在你想不到的時候發生了。資料已經恢復正常了！我擦！
倒推時間，倒推事件，是由於kafka重啟，導致資料回升的。
好吧，問題已經定位，kafka卡頓導致。咱們已經熬不住了，發個結論郵件，就先回去洗洗睡吧！
14. 為什麼kafka會卡頓？
這才是問題的根本！只是我們當時已經沒有力氣再往下搞了！
結論是由於topic請求量過大，而partition過小，導致吞吐量下降。將partition改大之後，終於真正恢復正常！
額，好像做了很多無用功，沒辦法 ！
看完本文有收穫？請轉發分享給更多人
關註「ImportNew」，提升Java技能
