本人主要從事遊戲後端開發，是以本文隻從遊戲開發角度分析Erlang使用中應注意的問題和優化點。
- 單節點還是多節點
Erlang節點之間的通信是透明的，節點内部和外部之間的調用一緻。基于這樣的特性，很多人會選用多節點，把各子系統(登陸節點，玩家節點，地圖節點，全局節點等)配置設定到不同的節點中，以支援更多的線上玩家。這樣做的出發點是好點是好的，但會引起一清單的問題:登陸、轉場邏輯複雜，節點間的消息廣播頻繁，玩家資料同步、一緻問題，記憶體消耗，運維複雜化等。相比之下，單節點就簡單多了，不用考慮節點通信，玩家資料保證一緻，運維友善，一機多服。在開啟SMP的情間下，單節點的性能已經很好。對頁遊的業務，同時線上達到5000人已經非常少見，即使達到也是首服當天才會出現，單節點完全可以應付這樣的情況，是以沒必要用多節點，增加系統複雜性。
2. 消息廣播
消息廣播是遊戲中的性能消耗大頭，主要包括地圖的行走、PK廣播，世界聊天廣播。世界聊天廣播可以通過CD等策劃手段限制，行走和PK包的廣播實時性高，隻能通過技術手段解決。地圖中的廣播包,隻需發給視野内的玩家就可以，不用全地圖廣播。視野内的玩家可以通過九宮格劃分，以 X,Y為主鍵，映射到對應的玩家資料。以九宮格方式查找玩家非常高效，我第一個遊戲，地圖中的玩家起初是儲存在一個清單中，每次廣播時都要周遊清單，找出同屏玩家，消息廣播非常低效，特别是在PK時，CPU占用高。用九宮格優化後，一切問題都解決了。還有一個優化廣播問題的方法是資料包緩存。
3. 緩存-資料庫，網絡
緩存是用空間換時間，它是性能優化中常用的方法。資料庫緩存，開服時把玩家的必要資料加載到記憶體中，可以減少玩家的登陸延時，應對玩家并發登陸，重新整理也很有效。同時玩家資料沒必要實作存庫，對于坐标，經驗，金錢等變化頻繁的值，如果實時存在，會很容易壓跨資料庫或對存庫程序造成消息阻塞。玩家改變的資料可以緩在記憶體中，定時存庫，或下線時再存庫。網絡中的消息包也可以在應用層給緩存起來，達到一定長度或延時一定時間後再發出去。雖然虛拟機和TCP層會做緩存，最好還是在應用層做一次緩存。
4. 程序-每玩家應該有幾個程序
其實每玩家一個程序已經足夠，代碼簡單，友善維護，性能開銷小。沒必要為每個玩家開啟了網絡，物品、任務等程序，多個程序不但造成程序間通信開銷，還不好維護。
5. 善用程序字典
Erlang中是不建議用程序字典的，但程序字典是資料存取最快的方式，對于遊戲這種高性能要求的應用，程序字典是不二的選擇。使用程序字典時要切記在對應的程序中操作，最好按功能把put,get操作封裝到子產品接口中，避免誤用。
6. 代碼規範
a. 代碼應該簡單，邏輯清晰，把功能細分到函數中。函數一般不多于30行，每個子產品不多于1000行。
b. 寫尾遞歸函數一定要有清淅的退出條件，不要在函數中改變退出條件。一個退出條件不明确的尾遞歸，是造成消息阻塞，記憶體耗盡的主要原因之一。
Erlang
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | %% 一個明确的尾遞歸函數: loop ( [ H | T ] ) - > do_something , loop ( T ) ; loop ( [ ] ) - > ok . %% 存在錯誤風險的寫法 %% NewLiist不可預期，存在死循環風險 loop ( [ H | T ] ) - > NewList = do_something ( H , T ) , loop ( NewList ) ; loop ( [ ] ) - > ok . |
c. 不要相信用戶端,上行的資料都需要驗證，前端的請求都要做合法性判斷，防止出現外挂、刷錢刷物品、刷金币的情況。
d 不要寫過多的case ,if嵌套，最好不要大于3個嵌套，通過 try catch 方法寫扁平化的代碼。
7. 自動化工具
自動化工具可以避免出錯，還把開發人員解放出來，提高生産效率。對于重複性，有規律的代碼(如資料存取，通信協定)，可以分離出來，讓工具自動生成。有了生成工具後，修改協定，新加字段等操作，簡單友善，不用為增加資料表中一個字段，而改十多個函數接口的修改;也不用擔心前後端協定不一緻的問題。
8. 監控系統
通過erlang:system_monitor/2，監控系統long_gc，large_heap等情況。
9. 性能分析工具
準備好top memory,top message_queue等檢視系統屬性的工具，出問題時可以随時檢視。
Erlang技術分享内容均為原創,轉載請标明本文位址
本文連結：http://www.kongqingquan.com/archives/221