開發中遇到的一些問題一
問題記載
問題記載 1
1、做好各個功能的性能評估 1
2、 任務結構調整 1
3、緩存的充要條件 2
4、數據散列設計帶來的問題 2
5、計算層和網關層的分層考慮 2
6、增加進程指定規則創建機制，原因在於： 2
7、排行榜，P25之前遇到的排行榜問題性能問題 3
8、P25大地圖的設計 3
9、其他建議 3
1、做好各個功能的性能評估
P28-17年7月24日渠道瞬時導量2w+，導致服務器承載超過上限服務器卡頓無法正常遊戲，玩家難以登錄當天維護兩次；
問題主要原因是，程序BUG+配置不夠，具體如下：
a、數據庫采用高效雲盤且只有兩個存儲節點，由於存儲節點相互備份性能甚至低於單節點，無法承載2W+的IOPS；
b、程序Bug，程序切換場景代碼存在bug，有玩家在服務器出現了一直切換場景的BUG，該BUG給計算節點帶來了較高負載；
c、最初現象是場景管理器處理業務超時，但不是主要原因，主要是上面問題引起。
解決辦法：
a、擴展存儲節點2臺為4臺，並切換為固態硬盤 ；
b、優化場景管理器，以陣營為一個單元進程在集群的各個節點當中；
c、增加中控，保證在遇到其他問題時可以立即開辟一個新的集群容納新來的玩家（主要是最近登錄服務器和充值消息的轉發）。
2、任務結構調整
之前任務產生的計算量以及數據庫訪問頻率較高，造成較多性能開銷，做了如下優化
P28最初設計參照傳奇掛機，任務數量為20個左右，所以直接在後端構建任務系統；
但後面任務數量一度擴展到500個左右，純後端構建任務和成就系統，監聽了遊戲中所有的行為負載較高，
且多次讀取數據庫造成了較高的數據庫IO和進程等待，所以重構了任務系統，前端推動和檢測，後端驗證結果CPU降低了不少。
3、緩存的充要條件
Erlang的緩存機制最常用的有Ets和進程字典，並依附於某個業務進程中，但分布式設計中需要盡量解耦，功能之間的聯系
除了代碼的直接調用就是數據之間的關系處理，我們希望的是節點盡量是無狀態的。
數據盡量不緩存於業務節點，處理不當將會直接影響節點的可伸縮性和安全性；
但是有些情況有必須緩存比如，P28包裹產出和消耗巨大，給數據庫帶來了較高負載，不得不重新考慮業務的實時性，將包裹緩存至會話進程每5分鐘檢查是否有變化，有則存儲否則退出時存儲一次。
4、數據散列設計帶來的問題
P28之前包裹、任務容器都是做的散列結構，一張索引表一張具體的物品表，優點是：
單獨獲取和操作指定裝備比較便捷，一條數據變動產生的文件偏移量變化小IO少，
最危險的就是數據斷鍵，造成索引和數據不一致，會導致很多垃圾數據的產生；
在P28上的問題是，遊戲產出和消耗裝備速度非常快，所以玩家進行熔煉N件的時候需要N次讀取和寫入，
我們即不能散列存放，因為操作頻繁；又不能整行存放，因為一件物品變化就會讀寫整個包裹數據。
所以，後面將包裹數據緩存到會話進程上，數據結構用整行存儲，因為頻率變低了。
5、計算層和網關層的分層考慮
P28的網關節點和計算節點的業務是在一起的，而P25則是分開的，我們的原因在於：
a、負載問題：計算節點的均衡負載需要自行實現zm_pid_dist的回調，回調函數的實現不受保障；
b、網絡問題：玩家受場景推動持續產生戰鬥行為和獎勵等事件，通信率高，所以場景被設計在了網關層；
c、業務問題：除了場景沒有較為密集高頻率的計算以及大數據自動分析管理的需求。
所以我們讓網關層和計算層運行在同一個節點上，業務交叉也方便些。
6、增加進程指定規則創建機制，原因在於：
P28有較多交互類活動是在不同進程運行但又需要數據共享，比如多張地圖同時陣營活動；
在正常情況下zm_pid_dist出來的進程會分裂到各個計算節點，可是我們希望同一個陣營的地圖進程創建到一臺物理機上，
減少血量，傷害，排名等數據的跨節點同步；比如在某個軍團挑戰軍團BOSS的時候，我們又希望同一個軍團創建出多張軍團BOSS的地圖也在同一個節點上。
雖然提出了這個機制，其實也有它的應用面，但是我們做這個解決方案是錯誤的。
血量同步，數據同步最好還是放數據庫的內存表，可以和策劃溝通戰鬥的即時性問題，血量1s同步一次就解決了這個高頻問題，所以這是一個過度開發。
7、排行榜，P25之前遇到的排行榜問題性能問題
1、之前實時排行榜采用的是分段處理保存，但是使用的是文件數據庫來保存，效率低，對於排行數據變化頻率比較高的那種排行榜，io的開銷比較大；
2、目前的優化，目前優化後采用的是內存榜，在服務器初始化時通過排行榜管理進程初始化排行榜，然後排名的更新等都在內存中操作，降低了io的開銷，提高了更新和獲取排行榜數據的效率。
而P28這邊的排行榜一開始就是以服務器為單位的進程存在集群的不同節點上。
8、P25大地圖的設計
之前大地圖采用的是滑到某塊區域去獲取數據庫的數據，滑動快獲取信息多，很容易造成性能瓶頸。
目前采用的場景進程的處理方案，在滑到某塊區域後獲取場景進程中管理的數據。
9、其他建議
a、唯一性提前控制，建議集群分段可采用cookie分段，在獲取唯一ID時不同集群采用各自分段ID，否則平臺BI將會出現相同數據;
b、大區概念，P28集群到現在仍然沒有大區概念，只有服務器概念，服務器中有對應的渠道則該渠道玩家就可以進入。
因為P28有陣營概念就去掉了大區，但後面運營的時候對於服務器管理產生了諸多影響，比如自動合服的時候
不能識別是不是同一個大區的，采用相同渠道號的服務器作為同一個大區進行相關業務處理的；
c、場景計算，每幀推動的時候會選擇目標，選擇技能，根據戰鬥者屬性計算傷害，可以考慮傷害計算好一次後不再計算，
後續繼續采用這個數值。
開發中遇到的一些問題一