1.3　能够承载多少玩家

服务端程序要承载很多玩家，性能是必须要考虑的问题。那么，1.2.4节的程序能够承载多少玩家同时在线呢？

1.3.1　单线事件模型

图1-11展示了1.2节程序的执行过程，无论何时服务端都是按顺序执行代码的。图中在时刻①，客户端A发送消息，服务端接收并处理。在①和②之间，服务端没有消息接收，进入等待状态。在时刻③客户端A和B同时发送消息，服务端收到后，先后执行。

有个专业术语叫“Reactor模型”，指的就是图1-11所示的程序执行方式，这里做个狭义的翻译——单线事件模型。“单线”指的是单线程，“事件”指的是事件触发，即当新连接、断开连接、收到数据这些事件到来时会触发某段代码。

图1-11　单线模型的时序图

1.3.2　承载量估算

要计算服务端系统的承载量，则要从CPU负载、内存占用、网络流量等多个角度考量，很难做到准确的估算，因为服务端运行在不同配置的物理机上，不同游戏类型的逻辑复杂度也不相同。但可以做个假设，假设在MMORPG中，玩家平均每3秒操作一次（走路、购物），服务端平均处理一条消息花费2毫秒。

从CPU的角度来看，同一时刻服务端只能处理一个客户端请求，按上述假设，服务端每秒可以处理500条消息，即最高可以承载1500人。

按经验推算，最高1000多人在线的游戏，日活跃用户（即每天登录的人数）大概是三五千。这种承载量对于多数独立游戏、小型手游是足够的。

知识拓展：尽管理论上CPU可以承载1000多人，但在实际情况中会低很多，而且这里只计算了CPU的负载，事实上，内存、网络流量也会对其有影响。“走路”程序受网络影响很大，因为玩家对服务端的响应速度有要求，总不能走一步等3秒钟后才有回应吧。如果不做进一步优化，广播的消息量与在线玩家则呈指数增长关系，通常这类单线程程序只能支持几十名玩家。