这是一个好的多线程服务器设计吗？

Question

我有一个用于客户端-服务器游戏的服务器（理想情况下是小型 MMO 的基础），我正在尝试确定组织所有内容的最佳方式。以下是我所拥有的概述：

[server start]
load/create game state
start game loop on new thread
start listening for udp packets on new thread
while not closing
  listen for new tcp connection
    create new tcp client
    start clients tcp listener on new thread
save game state
exit

[game loop]
  sleep n milliseconds // Should I sleep here or not?
  update game state
  send relevant udp packet updates to client
  every second
    remove timed out clients

[listen for udp]
  on receive, send to correct tcp client to process

[listen for tcp] (1 for each client)
  manage tcp packets

对于管理游戏状态、tcp 连接和发送/接收 udp 数据包以进行状态更新，这是一个公平的设计吗？有什么问题或问题吗？

我最感兴趣的是进行游戏循环的最佳方式。我知道如果我有大量客户端，我会遇到问题，因为我会为每个新客户端生成一个新线程。

Answer 1

这看起来是一个合理的设计开始。就扩展线程数量而言，超过 10 个客户端（根据您的评论）也不错。只要线程主要在等待而不是实际处理某些东西，您就可以在事情开始崩溃之前轻松拥有数千个线程。我记得 5 年前类似的设计遇到了一些限制，大约是 7000 个线程。

Answer 2

看起来不错的设计。如果我是你，我会使用现有的 nio 框架，例如 netty。

只需 google java nio frameworks，您就会发现几个带有示例和文档的框架。

更新

谢谢，但我更喜欢自己做。这只是我的一个副项目，它的大部分目的是

恕我直言，通过使用现有框架并专注于游戏设计，您将学到更多知识，而不是从一开始就自己做所有事情。

下一次你会知道如何设计游戏，这也使得设计 IO 框架变得更容易。

Answer 3

我想说的是（尤其是）在 Java 中，线程更多是为了方便而不是为了性能（只有太多的内核，我猜你想控制哪些线程具有优先级） .

您没有提及消息交换量和客户端数量，但您可能希望从单线程处理网络 IO 的角度考虑更自然，并让它以紧凑的方式调度传入的请求循环，并将实际工作（即您无法在紧密循环中处理的请求）映射到线程池。 IIRC，在这种设置中，限制因素将是您可以在单个线程中同时等待输入的最大 TCP 连接数。

为了增加乐趣，将其与具有更多轻量级线程的语言的解决方案进行比较，例如在 Erlang 中。

当然，正如@WhiteFang34 所说，在您对代码进行一些认真的模拟/使用之前，您不需要这样的解决方案。相关技术（以及可以从中找到灵感的 Netty 等框架）也可以在 this question here 中找到。

创建线程是有一定成本的，mostly the per-thread stack。