为了回答你的问题,我们需要了解你需要的是容量还是响应速度,但同时获得两者是很困难的。
第七层负载均衡 - 是基于数据应用的负载均衡,在此,网络数据包的数据内容需要被路由到一个终端点。您可以通过在应用程序级别、服务级别或内核级别实现路由来实现容量(更多用户)。
可扩展性 - 我假设您会遇到内存、CPU资源和网络带宽等瓶颈问题。
- 应用程序级 - 您的应用逻辑接收应用程序数据包并进行相应的路由。
- 服务级别 - 您的系统框架(一种前端服务)接收数据包,并通过一个模块执行路由(例如自定义Apache模块,甚至网络驱动程序模块 - 就像编写网络过滤器一样)。
- 内核级别 - 在网络数据包级别上执行路由。
越靠近硬件层级,响应速度就越好。我建议使用专用的Linux服务器来执行路由 - 原生地去做,而不是虚拟化。对于广域网使用多个或团队化的网络适配器,每个端点使用一个专用的适配器(一个以上的广域网,每个连接的应用服务器各一个)。
如果响应时间很重要,那么您需要使用内核/监管状态解决方案,这将节省一些上下文切换,但请注意必须尽可能限制跳数,最好使用较少的、更大的机器,而您的扩展性将始终受到限制。使用KTCPVS存在风险,因为它相当老旧且没有得到积极更新。如果您认为它适合您,那就太棒了;否则,请考虑编写类似于网络过滤器的东西,只要它在系统状态下运行即可。
如果容量很重要,但响应时间次要,实现一个自定义高速套接字交换机,在问题/用户状态下使用C ++构建,这是最易于维护的,并且将提供最佳的可扩展性。
您需要建立一些原型来找出最适合您需求的解决方案。
最后的想法 -
在进行上述任何操作之前,请先确保优化了游戏设计。您可能已经知道其中大部分,我在此列出以造福所有人。
(a) 消息应该适合一个网络数据包,对于大多数家庭路由器来说,少于1500字节。
(b) 尽可能在游戏客户端中处理路由逻辑,而不是服务器。通过向客户端简单下载包含区域和IP地址的小表格,您可以避免上述所有问题。
(c) 尝试通过将区域可见性限制在客户端内来减少负担,这些客户端仅需知道其所在区域和相邻区域(如果您实施了上述b点)。
希望这有所帮助,抱歉我无法就KTCPVS提供更具体的信息。