一、目標(biāo)
能橫向擴(kuò)展，架構(gòu)要簡單，能做到負(fù)載均衡，避免單節(jié)點負(fù)載太輕的資源浪費。
二、數(shù)據(jù)存儲的DB集群
數(shù)據(jù)存儲類型有多種。
（一）非交互性的個人數(shù)據(jù)
可通過簡單的id分段。id為1~10000的玩家個人數(shù)據(jù)存儲在db1，id為10001~20000的玩家個人數(shù)據(jù)存儲在db2，以此類推。
（二）交互性數(shù)據(jù)
如好友關(guān)系等。
（1）如果好友關(guān)系可以為單向，那么可以將關(guān)系存到個人數(shù)據(jù)里。
（2）如果好友關(guān)系不能為單向，那么需要保證每條關(guān)系保持在要么沒有，要么兩人都認(rèn)同，記數(shù)據(jù)上一直，互相有關(guān)系。那么需要保證相關(guān)的關(guān)系操作的一致性。這樣可能只保存一份每兩個人之間的關(guān)系，k-v存儲時需要方向查找，不知是否能實現(xiàn)。
（三）全局?jǐn)?shù)據(jù)
如全局排行榜之類的。這種放在單獨的庫里里，專門做全局?jǐn)?shù)據(jù)的存儲。當(dāng)?shù)揭欢ㄒ?guī)模時，按全局?jǐn)?shù)據(jù)的類型再分庫。
家族、幫會等，也放單獨的庫里。如果需要擴(kuò)展，再按家族id、幫會id來分庫。
三、邏輯服務(wù)器集群對DB集群的訪問
DB集群的路由規(guī)則配置到邏輯服務(wù)器的config里。當(dāng)需要熱擴(kuò)展DB時，啟動新DB后，給各logic服務(wù)器發(fā)送GM指定，reload路由規(guī)則的config。
DB集群路由規(guī)則的config，可以放在一個公共地方，各logic服務(wù)器接到GM指令后，去公共地方拉取新的config然會reload。
四、邏輯服務(wù)器集群
為了架構(gòu)的簡單，可以每個邏輯服務(wù)器進(jìn)程上都有所有邏輯，擴(kuò)展時，以擴(kuò)展邏輯服務(wù)器進(jìn)程數(shù)量來達(dá)到。
（一）各邏輯服務(wù)器上玩家分配
邏輯服務(wù)器集群之間的交互。如果邏輯服務(wù)器的使用，也像個人數(shù)據(jù)存儲的DB那樣id分段——只讓1~10000的玩家登陸logic1，10001~20000的玩家登陸logic2時，這很簡單，但各id斷的玩家活躍度不定的，做不到負(fù)載均衡啊。
所以是根據(jù)當(dāng)時的負(fù)載情況，來推薦玩家登陸閑的邏輯服務(wù)器的。這樣需要有個全局映射，知道哪個玩家登陸在哪個服務(wù)器上。可以將玩家當(dāng)前所在的服務(wù)器id記錄在該玩家的個人數(shù)據(jù)所在的db里。
（二）邏輯服務(wù)器間的通信
目前項目持久化使用redis，最快出東西，就先考慮redis的優(yōu)勢。
邏輯服務(wù)器間的通信，通過全局?jǐn)?shù)據(jù)存儲的redis來做pub/sub轉(zhuǎn)發(fā)吧。
redis的pub和sub的實時性不夠時，將有實時性需求的玩家都轉(zhuǎn)到一個專門做強(qiáng)實時性的特殊邏輯服務(wù)器。
五、PS
公司的項目是Node.js+Redis，業(yè)余時間打算用Go寫個服務(wù)器引擎。
這篇考慮發(fā)到精華區(qū)，可以得到很多的批評建議。