這個問題是我在面試相關資深服務器工程師時必問的，我想得到的答案不一定要求全面。

其實我最關心的是：作為一個服務器端的工程師，咱們應該具備在遇到問題時能有效的處理這個問題的能力和自信。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

凌晨0:31，剛上床的苦逼服務器電話鈴聲又響了，論壇刷爆了....

游戲進不去了。。。。戰斗卡的一逼。。。。

我X。。。。尼瑪。。。什么破玩意兒。。。。靠。。。。給勞資賠償。。。。

大伙，一起告他Y的去，找工信部投訴。。。。給咱們賠償。。。

微信里面老板咬牙切齒的說：“什么情況，怎么又是問題，什么時候可以解決!!!???”

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

這個場景我相信做過幾年游戲的應該都不陌生。

下面我就談談自己的見解，當然一個人的想法肯定是不全面的，還請大家多指教.

1：針對玩家所說的卡，首先我們得確認一個事實：卡頓和延遲

卡頓：是客戶端由于某種邏輯處理不當造成的界面UI反映慢，或者點擊沒反應，甚至導致客戶端直接崩潰。

延遲：一般的表現是，界面操作順暢，但是數據反映慢，最直接的就是像按鈕點過之后要等一段時間才能看到結果。

這個問題一般的方法就是讓自己的人進游戲看一眼，同時檢查一下服務器負載、數據庫壓力；

一般情況下3、5分鐘就可以得到準確的答案。

之所以這個放在第一步：是應為只有確認了這個之后，咱們至少不會在客戶端卡頓的情況下亂查一頓服務器log，因為一般情況下服務器都會有那么一兩個慢操作的log記錄，

這回很影響咱們的嗅覺，總覺得這里有問題，但是又不能確定。最終在這里耗費了很長時間都得不到結果。

而且最煩的是運營的同學老是在追問進度 —— “問題查的怎么樣了？ 什么時候能好？ 要不要回檔？”

2：在弄清楚第一個問題后，如果排除了客戶端的卡頓，那么咱們就可以斷定這個“卡”至少不是客戶端的同學造成的。

那么現在還有兩個可能，A:服務器反映慢、B:網絡慢

最直接的辦法就是看下top信息，看下服務器負載，如果當時的負載很高，那么8成就是A了。

如果發現負載很低，接下來就要想辦法查一下網速了，如果發現網速確實不正常，那你就可以聯系運維的同學，讓他們幫忙聯系機房那邊協同處理

3：在第二步排除網速問題之后

我一般是直接tail一下log，一般數據庫要是有問題我們的log應該是最能說明問題的了。

如果定位到是哪個表出問題了（MySQL有時候會有表損壞的情況）如果你的服務器有對于的防護措施的話，可以直接修復這個表。

如果沒有防護措施，那就只好關服，修復數據庫，然后在開服

4：在第三步排除了數據庫問題后，這時候估計已經過了大概10-15分鐘了。

老板有點等不及了，因為對于一個游戲來講，時間直接影響這個月的流水。

如果你的服務器是多進程的，在不影響游戲的情況下你可以采取重啟部分問題進程的方法暫時解決這個問題。如果只有一個進程，那就只好重啟游戲了。

當然在這之前，你應該花1-2分鐘的時間來做下面這幾件事情。

找2到3個服務器（最好能找一個正常的）

a、查看一下當時java進程的gc情況，并把它記錄下來。

b、把這幾個服務器的整個堆dump下來。

c、保存log信息（這個一般服務器都會有相應的保存機制的，不過安全起見，最好還是留一個心眼）.

d、如果可能，記錄一下當時的在線人數等信息。

e、通知運維和運營，準備重啟問題服務器。

有人可能要說了，這問題還沒找到，就重啟了？？？

我的答案是，如果咱們有自己的測試流程，已經在測試環境下測過是沒有問題的。

那么它可能就是一個比較隱藏的bug，或者是內存問題，短時間內不會暴露出來。那我們就可以利用這個時間和之前得到的這些信息來排查問題

我相信，對于一個有幾年經驗的Java工程師來說，在有足夠的信息的前提下，排查一個問題不會花很長時間。

如果在一個通宵后，你定位到了這個問題，那么恭喜你。第二天你可以堂而皇之的倒半天休。

接下來就是安排一次服務器維護了....

-----------------------------------------------------------------------------------

未完待續。。。