游戏服务端高并发和高可用，怎样支持百万玩家同时在线，不出问题

用通俗的方法来描述一个好的服务端架构，最基础也是最重要的就两点： 支持百万玩家同时在线，不出问题 。这两点也就分别对应了高并发和高可用。

这篇文章系统的介绍游戏服务端中的高并发和高可用。

高并发和高可用是一个相辅相成的工作，当我们支持百万玩家同时在线时却无法保证服务器稳定可用，那高并发支持就无从谈起；而如果当玩家数量较多时服务器就常常出问题，那也不能称为高可用。

一、水平扩展

水平扩展是高并发和高可用的基础，通过支持水平扩展，我们理论上可以通过增加机器获得无限的承载上限，从而支持高并发；在此基础上，若某个进程出现异常，其他进程可以替代其提供服务，从而实现了高可用。

以下图为例，对于不支持水平扩展的架构，游戏服务器中只有一个战斗进程为所有的玩家提供战斗服务，这里存在两个问题：1.一个进程最多只能使用一个一台机器的计算资源，存在性能上限。2.若这个进程或者所在机器/网络发生异常，那么整个系统就不可用了。

 

不支持水平扩展

水平扩展有两种常见的实现模型：

• 大厅服和所有的战斗进程进行全连接，需要访问战斗服务时去管理器中查询服务所在的进程地址，然后直接去访问进程。（左图）
• 在战斗进程前面挂一个路由，路由记录每个战斗所在的战斗进程，相关请求会转发到对应的进程。（右图）

水平扩展的两种模型

1.1 有状态 vs. 无状态

从进程内存中是否保存状态的角度可以将服务分为有状态和无状态：

• 有状态服务：进程内存中保存状态，比如战斗服务将战斗信息（玩家角色状态、小怪状态等）保存在内存中，玩家操作或者战斗逻辑会改变战斗信息。由于游戏中状态比较复杂，业务改变状态频率比较高，游戏大部分的业务都是用有状态服务的方式提供。
• 无状态服务：服务只处理流程，不保存数据，一般数据会保存到后端db中，这种服务的逻辑一般会有很多db操作。这种类型的服务在互联网web行业用的比较多，游戏中常见的比如充值、登陆等。（无状态服务在执行一个流程处理中可能会有一些临时变量申请内存）

无状态服务本身不保存状态，所以进程crash也不会丢失信息。此外，下文将介绍，由于使用随机分配的路由方式，无状态服务对异常的容忍更加好，所以，从高可用角度，无状态更加好。

但是，由于无状态不保存状态，所有状态操作都是数据库操作，就造成了开发成本更高（代码写起来更复杂）、数据库压力更大，所以无状态并不适合所有服务，一般对于状态简单明确的服务，可以优先使用无状态，比如好友服务。

1.2 路由策略

对于有状态和无状态服务，他们使用的路由方式也不同。

对于无状态服务，一般使用 随机分配 的路由方式。随机分配的路由方式有很大的好处，如果某个进程crash了或者网络出现了故障，我们只需要把这个进程从路由中去掉，对后续的请求不会有影响，只会影响此进程当前正在处理的逻辑。

有状态服务的路由需要明确每个请求给哪个进程处理，给其他进程其他进程因为没有相关状态信息也无法处理。比如上文提到的战斗服务，路由根据战斗ID将相关请求发给对应战斗所在的进程中才能处理。路由一般使用 取模 或者 一致性哈希 ，一般会优先使用一致性哈希而不是取模，防止故障引起抖动。

1.3 举个例子

下图是某游戏架构的简化版模型，真实的服务器比这个