寫這篇文章是對自己2011bug戰斗時光一個交代，隨著時間的推移，當初印象深刻的痛苦和壓力慢慢消逝，到現在甚至是需要很長時間來弄清楚這中間的關系，趁著現在頭腦還算清楚，記錄下吧。
場景管理
為了說明Bug產生的原因，先描述下場景管理的實現方式吧。
1、游戲場景是游戲地圖的一個實例(假設地圖是class)，一個地圖可以創建多個場景，場景主要負責管理玩家的移動、廣播等處理。
2、場景的廣播是采取經典的九宮格方式來實現的，每一個格子的我們定義為Area對象,一個場景的格子組成其實是一個二維數組。
3、玩家進入場景的時候，根據坐標可以知道要進入哪個格子，每個格子內會保留一個Head指針，標記最新進入的玩家對象。玩家對象上有2個指針，標記玩家所在格子的前一個和后一個對象。可以通過格子內的Head指針便利Area內的所有玩家對象。
4、玩家移動切換格子的時候，先從原來的格子內Leave，這會調用原來Area對象的Leave函數。再進入新的格子，調用Area的Enter函數。很明顯，Leave函數就是一個鏈表刪除操作，如果玩家是Head，則設置新的Head。
Enter操作就是將新進入的玩家鏈接到原隊列里，新進入的玩家會被設置為Head。
問題表現
根據上面的描述，如果一切按照正常程序，這個方案運轉是沒問題的。最初上線的時候，也沒有出現問題，但是在出了一個資料片之后，服務器基本上每隔半小時左右就會發現有死循環或者宕機問題。
死循環的表現很明顯，就是在遍歷場景玩家的時候，出現死循環。宕機則更加復雜些，每次宕機位置不同，總的來說大概有3-4個地方，每個地方單看都不合常理。
直接分析上面的表現，都找不到真正的的原因，只好擴大搜索范圍了。
比較倒霉的是那個資料片的主要系統都是我開發的，所以自然嫌疑最大，然后大家集中精力來分析我的代碼，由于每個人風格都不同，所以大家看的不太明白的地方都會來問我，所以那個晚上基本就在解答設計疑問了。
被輪了大半個晚上，知道凌晨2點，大家也沒分析出問題，只好先回去睡覺了。結果早上7點，測試給我打電話了，沒辦法只好跑過去了，一到公司，發現圍了一堆老大，老大們很嚴肅：這個問題很嚴重，必須盡快解決。
沒辦法，只好繼續上陣了，戰斗到下午2點，突然靈光一閃，想到了原因，當時感覺真的心力交瘁了，更加感慨的是其實這個問題真和我沒啥關系。。。
原因
真正導致這次事故的其實是一個小操作:玩家重登錄(手機玩家斷網的時候，服務器會保存一段時間在線狀態)的時候，有的時候由于其他原因，會卡在不能地圖的物理層(不能行動的點)，玩家完全不能移動。為了解決這個問題，有個同事在玩家重登錄的時候，直接設置了玩家的坐標到一個可移動的點。
這個看似無關緊要的操作，真正導致了服務器1天多時間內不停的宕機。下面來記錄下分析過程吧。
1、玩家在重登錄前，其實是在場景中的，也就是在一個具體的Area里。
2、由于玩家上線后，直接設置了坐標，而我們后續的計算是通過坐標來獲取Area對象的，其實這里就出現問題了，玩家其實是在A格子的鏈表上，但是根據坐標計算獲得的格子是B。
3、玩家移動后，切換格子，需要從原格子Leave,然后進入新的格子，但是基于上面的原因，所以其實涉及到的有3個格子，(1)、玩家真實所在的格子鏈表(A)。(2)、通過坐標計算所得的格子(B)，這個格子對象上會調用Leave操作。
(3)要進入的新格子(C)。
4、由于玩家其實在格子A,但是我們調用的是B.Leave(player);C.Enter(player)，從這里看，肯定是有問題的，但是細看則不然，由于玩家對象是記錄了前一個和后一個對象，所以B.Leave本身并不會破壞B的鏈表結構，C.Enter看上去也沒問題，那么，問題在哪里？
5、真正的原因其實是格子A對象被破壞了，B.Leave(player)上是將玩家從它自己的鏈表上刪除了，鏈表本身是沒有被破壞了，關鍵的原因是如果玩家在格子A是Head,那么實際上在玩家被刪除后，Head應該被改變，但是由于操作的是格子B，所以，A其實被破壞了，很奇妙，這個對象沒有操作，卻被破壞了。后面的問題就簡單了，如果玩家進入的C就是A,則會是一個很明顯的死循環，如果玩家進入的C是一個新的格子，則格子A的對象都不能被感知了。
posted on 2012-07-15 22:13
feixuwu 閱讀(422)
評論(0) 編輯 收藏 引用