游戏服务器的单进程

最简单的游戏服务器只有一个过程，便是点射。假如这一全过程撤出，整个游戏全球都是会消退。游戏服务器托管。在这个全过程中，因为需要解决高并发的客户端数据文件，有很多挑选方式 :

每一次接受到客户对话时，都是会创建一个进程。这一客户对话通常是用客户端的TCP连接来表明的，那样每一次启用一个包从tcp协议中读写能力，都可以使用堵塞方式，编号形象化简单。游戏客户端的线程数和连接数一样多。可是这类方案也是有显著的缺陷，便是服务器非常容易产生很多的进程，难以控制内存占用，进程转换也会导致CPU的性能损害。更关键的是，线程同步下读写能力同一块数据信息需要解决锁问题，这很有可能会使编码越来越比较复杂，导致各种各样死锁bug，影响服务器的稳定性。

为了更好地节约进程的建立和释放出来，创建了线程池。当每一个客户对话创建后，应用到线程池以供解决进程使用。当客户对话完毕时，进程不会撤出，只是将该进程的使用“释放出来”给线程池。线程池可以非常好的控制进程总数，避免客户猛增对服务器导致连接冲击性，产生排长队体制。可是线程池自身的完成非常复杂，需要严格执行“应用”和“释放出来”进程的启用标准，不然会出现进程泄露，耗光线程池。

在游戏领域，为了更好地得到高性能，使用Linux的epoll做为网络API是一种普遍的挑选。游戏服务器过程中最普遍的堵塞启用是网络IO，因此使用epoll后，整个服务器过程很有可能会越来越彻底沒有堵塞启用，因此只需要一个进程。那样完全解决了线程同步的锁问题，简单化了并发编程的难度系数。可是“全部语音通话不可堵塞”的约束方程并并不是那麼非常容易遵循的。例如一些数据库API被堵塞；此外，单独过程、单独进程只有使用一个CPU，没法充分利用现阶段多核多CPU服务器中的CPU資源。异步编程是基于“回调函数”的，这就造成 许多调用函数被界定，一个过程中的逻辑性是用几个不一样的调用函数来写的，这对编码的载入是十分不好的。针对这一编号问题，coroutine可以更强的协助，因此如今时兴多线程和Coroutine的融合。不管怎样，多线程单核实体模型依然是很多精英团队的优选 ，因为它性能好，不需要高并发逻辑思维。

这是一个基于多线程单核实体模型的演变实体模型。这一实体模型一般有三种种类的进程:主线任务程、IO进程和逻辑性进程。这种进程在內部都以彻底多线程的方法运作，他们根据一个无锁的消息队列相互通信。有不明白的请咨询微云网络服务器了解。