stick-战斗服管理器横向扩展

一个服务器组有 一个战斗服管理器N个战斗服M个网关，这个NM的数量取决于机器配置。

上篇后续   BattleServer负载均衡

尽管战斗服管理器处理能力足够在N=15 M=15的情况下，预计N M 呢能达到50 才是一个管理器的上限。但是如果百万千万级DAU下的游戏也是扛不住的，因此管理器需要横向扩展。在这里的关键是开黑房间的处理，。开黑房间号是一个短数字，全服唯一。

服务器组1 和服务器组2 他们在不同的物物理机上，

方案1：各自的管理器负责不同区间的房间号生成，，基本思路，管理器收到加入开黑房间号后现在本服务器组找，如果没有再去redis里面找。 管理器之间通过redis来共享开黑房间信息。那么新问题又来了，redis中的数据的有效性和及时性，这种体验非常不好，其他管理器拿到了脏数据，客户端却链接不上。思考过几种解决这个问题的方案，都不太理想。

方案2：管理器之间互联，通过房间号生成区间来找到目标管理器确认该房间号信息，这样就不用通过redis共享了。

方案2可行性较大，网关链接各自服务器组的管理器，管理器链接各自管理器的额战斗服，不同的服务器组间的管理器全互联

方案3：在方案1的基础上，链接多台redis，纯临时数据 和可持久化的数据，前者可以随便清空。后者开启持久化，在这点上可以考虑用memcache 做前者，redis做后者，双redis也可以

最终方案，服务器组网关全互联。管理器全互联，管理器之间相互发消息，不用redis来中转，房间号里面包含了组信息。

另外一个处理是如果当前管理器分配失败表示该服务器组负载非常非常高，那么可以尝试吧请求转发给另外的管理器来处理。这个问题另外开篇讲述，管理器的负载均衡