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