我看了BrowserQuest的實(shí)現(xiàn)，在WORKER里創(chuàng)建了世界，世界里面的怪物區(qū)域采用TIMER進(jìn)行刷新和AI處理，這個(gè)游戲業(yè)務(wù)邏輯比較簡單，玩家也少，如果同時(shí)承載大量玩家的話，感覺這個(gè)WORKER響應(yīng)會(huì)出現(xiàn)延遲。

現(xiàn)在我想實(shí)現(xiàn)一個(gè)MMORPG的游戲，用GateWayWoker的模型，如果把怪物也按照BrowserQuest放到一個(gè)WORKER里，應(yīng)該會(huì)有很多問題，我想了一種解決方案，請(qǐng)大神幫我評(píng)估一下，如果這樣做不好，有沒有什么更好的方案。

在現(xiàn)有的GateWayWoker基礎(chǔ)上，新增幾種地圖WORKER類型（以下簡稱MAPWORKER）與GATEWAY異步連接，MAPWORKER根據(jù)地圖邏輯復(fù)雜程度開啟相應(yīng)的進(jìn)程數(shù)量，GATEWAY在第一次收到用戶客戶端登錄消息后根據(jù)所處地圖的ID綁定對(duì)應(yīng)的MAPWORKER，此后與地圖不相關(guān)的信息全部轉(zhuǎn)發(fā)給BusinessWorker處理，如聊天，倉庫等，與地圖相關(guān)的發(fā)送到當(dāng)前所屬地圖MAPWORKER，如移動(dòng)，攻擊等，各個(gè)MAPWORKER里用TIMER處理地圖邏輯，如定時(shí)刷怪，AI等并將信息發(fā)到GATEWAY發(fā)給客戶端。

這樣做可以把每個(gè)進(jìn)程的業(yè)務(wù)邏輯延遲降低、也可以分布式提高性能，但是不可避免的會(huì)出現(xiàn)共享數(shù)據(jù)的存儲(chǔ)問題，畢竟MMO里需要廣播的場景太多，哪怕移動(dòng)一步，說一句話，都可能導(dǎo)致廣播數(shù)十乃至數(shù)百，如果每次都依靠實(shí)時(shí)從MEMCAHE或者REDIS之類的拉取，玩家多起來，估計(jì)這個(gè)地方會(huì)有點(diǎn)壓力，玩家并發(fā)少問題應(yīng)該不大。