游戏服务端的高并发和高可用( 二 ) 文/水风本文首发知乎

有状态服务
在我们游戏的服务器集群中，三分之二左右的进程是处理玩家个人逻辑的进程（玩家集群，很多游戏项目叫大厅服务器）。每个进程处理一部分玩家的业务逻辑，通过shading将玩家分配在不同的玩家进程中。
可以通过增加个人逻辑进程数量提升服务器承载量，我们支持不停服增加或减少进程即动态扩容缩容。，这些进程之间就是平等的，不同进程之间没有强依赖关系。当一个进程crash时，他不会影响其他进程的玩家。
除了玩家进程，还有战斗进程、家族进程等类似进程可以这么设计。
上面提到的都是有状态服务，我们需要记录每个玩家/战斗/家族在哪个进程中，此外，若进程出现异常，虽然不会影响其他玩家/战斗/家族，但当前进程中玩家/战斗/家族都会不可用，而且会丢失一些数据。
无状态服务
我们将部分服务使用无状态实现，比如登陆、支付、好友、部分排行榜等。由于无状态服务具相对于有状态对异常更友好、动态扩容缩容模型更简单，因此有对于一个新的服务我们优先考虑使用无状态，若状态较复杂才考虑使用有状态服务实现。
单点服务
游戏服务中难免出现一些单点服务，比如玩家管理器、集群管理器、家族管理器等，这类服务不具扩展能力，是游戏服务器的承载瓶颈。此外，也不具有高可用性，如果出现异常会导致导致整个游戏集群不可用。
单点服务逻辑普遍简单（复杂逻辑我们都要支持水平扩容），性能承载普遍较高。比如，我们游戏中目前评估的同时在线保守估计应该在50w ，此时我们认为我们的一些单点服务会出现满载，导致游戏无法继续扩容。
此外，单点服务数量较少，出现异常的可能性很低。我们游戏上线近两年，我们也只遇到了两次机器宕机，影响的都是非单点进程，没有影响整体的游戏集群可用性。
当然，单点服务也可以改为支持水平扩展的，只是工作量的问题。理论是来说，是能完全消除单点的，只是对于大部分项目来说性价比不高意义不大。
2高并发
水平扩展的方案是支持高并发的主要手段（也叫可伸缩Scalability），上文已经介绍过了。
下文主要介绍除了水平扩展高并发的其他方案，以及需要注意的点。
2.1垂直扩展和性能优化
要提升承载能力，一般有两个方案：
水平扩展：通过增加机器数量提升承载能力。垂直扩展：通过增加机器配置提升承载能力。让一个机器/线程可以承载更多的玩家。垂直扩展在某些场景也有有用。一般来说，对于上文我们提到的单点，如果不好消除或者消除成本很高，可以通过垂直扩展把这个逻辑放在高配机器上，提升单点逻辑的承载。
此外，我们常常是对战斗服进行性能优化，比如使用C++写高消耗模块，但对于大厅服一般不将其作为提升承载的首要手段。这个我们不深入讨论，一方面这个总会有上限，难有质变，另一方面不同游戏优化方案千差万别，都是代码级别的优化。
服务端优化和垂直扩展的目标类似，就是让一台机器能承载更多的玩家/逻辑。
2.2消除系统单点和逻辑单点
上文介绍的消除单点主要是系统单点，也就是用多个进程而不是一个进程提供服务。
消除系统单点的前提是消除逻辑单点。
举个例子：我们投放一个武器时，要给这个武器生成一个全服唯一的ID以标识此武器。这个ID可以使用一个自增的ID ，此时就造成逻辑单点。
对于这种情况，如果游戏中生成武器的频率很低，那么这种方案也可以，但如果武器生成频率很高，因为游戏中所有逻辑都需要去一个地方去申请这个ID ，那就可能产生瓶颈。对于这种情况，我们一般可以使用uuid代替自增ID 。（这个场景也常见于DB中的自增列，所以一般建议少使用自增）
2.3数据库承载
当玩家在线量达到一定的量级以后，往往对后端的数据库造成很大的压力。
一般来说，数据库本身具有水平扩展能力，加上分库分表等方案，提高承载能力比较容易。但设计数据库结构时也需要考虑索引、shadkey等问题，不然严重影响数据库性能。此外，要考虑数据库并发读写能力，比如mongo中的MMAPv1存储引擎是collection级别锁,而WiredTiger存储引擎是doc级别锁，两者的并发能力差别极大。
游戏逻辑普遍比较复杂，数据读写量很大，如果每次玩家信息变更都去读写数据库，会造成较大的数据库压力。因此，游戏的玩家服务一般都是有状态服务，玩家上线时将数据从数据库读到内存中，在线期间读写数据都是直接操作内存，下线时或隔段时间去落地到数据库。这种方案大大降低了数据库读写操作，对数据库压力会小很多。