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

而一些数据读写操作频率较低的服务，可以考虑将服务做成无状态然后每次读写都去操作数据库。
2.4多集群和跨集群
当游戏服务端达到一定的规模后，往往需要分集群部署，分集群解决的场景：
单集群的承载具有上限，比如skynet只支持256个进程。多区服需求，每个集群对应游戏的一个区服。如果游戏支持多区服并且完全隔离没有跨服通信，实现高并发会容易很多。全球通服，某些集群希望部署到玩家所在地区。比如美国玩家所用的战斗服部署在美国，东南亚的战斗服部署在东南亚，而他们共用大厅服部署在某地。多集群中需要解决的一个问题是跨集群通信问题，集群内一般是进程间全连接，但集群间如果进程全连接会造成拓扑混乱连接数量爆炸的问题，因此集群间通信一般使用消息总线，所有的集群通过消息总线进行通信。

文章图片
2.5临时的高并发
在游戏业务场景中，玩家的在线和时间、活动等关系很大，不同的时间在线数量可能有几倍几十倍的差别。
对于预期内的高流量，可以通过提前做好扩容来进行承载，参考《忍三的服务端优化》中的“动态扩容和缩容” 。
对于非预期的瞬间高并发，可以通过排队系统将流量卡在系统外，动态扩容后再慢慢的进入游戏中。
2.6战斗场景中的高并发
游戏还有一个特殊的高并发场景，就是MMO的大规模玩家在某场景聚集，比如国战。
这种场景没有完美的解决方案，只能尽量的提高承载量，常见的提高方案有：
将一个场景切分为cell ，不同cell放到不同进程。比如bigworld/kbengine和最新的SpatialOS 。提升单进程承载能力。比如逻辑优化、垂直扩展、使用C++写游戏逻辑等， C++和python比起来性能有数量级的差别。服务降级：简化游戏逻辑，比如国战时一般只要玩家觉得场面热闹就差不多了，很多战斗逻辑其实都简化掉了。分服/分线/分副本：业务上让玩家隔离。我之前有篇文章《游戏的数值系统的实现和演化》写过我在之前一款游戏中做的战斗服务端性能优化。
3高可用
高可用追求系统在运行过程中尽量少的出现系统服务不可用的情况。
评价指标是服务在一个周期内的可用时间（SLA ， ServiceLevelAgreement），计算公式为服务可用性=（服务周期总分钟数-服务不可用分钟数）/服务周期总分钟数×100% 。
一般从两个维度进行评价：1.系统的完全可用：所有服务对于所有用户都是可用的。 2.系统的整体可用：部分服务或者部分用户不可用，但系统整体可用。
高可用的目标是争取系统的完全可用，保证整体可用。
大集群下的异常
由于机器故障、网络卡顿或断线等客观存在的小概率异常情况，服务端也需要考虑这些问题，尤其是在大集群场景下，小概率事件累加变成了大概率事件，因此在大集群服务器场景下，高可用是我们必须要考虑的问题。
高可用，其实就是对各种异常状况的隔离和处理，不让小概率异常事件影响游戏的整体服务。
常见的异常有以下几种：
机器/进程/网络异常：阿里云机器的可用性承诺是99.975% ，大概是每台机器保证一年的不可用时间在1小时以内。若集群使用一百台机器，理论上来说最差的情况是每三天就有一台机器一小时不可用。当然，真实的可用性比阿里云承诺的好很多，我们游戏大概有100台ECS机器，一年中有两台机器因为机器故障自动重启，并没有出现过持续的不可用。 Saas服务/DB异常：因为我们大数量使用了阿里云的mysql、redis等云服务，这些服务本身也有可用性问题，导致主从切换等。我们游戏最常遇到的问题是因为redis主从切换造成网络闪断需要网络重连。业务BUG：对于业务BUG ，尽量有办法减少bug的影响，不让某些小BUG导致系统整体不可用。突发性能热点：玩家的正常行为或异常行为导致的业务图发繁忙，主要是上文所说的高并发问题。此外，对于某些玩家的异常行为（比如外挂DDOS攻击），也要保证不会影响系统整体可用。我记得很早之前（传奇年代），有些外挂能直接让服务器重启。3.1基于水平扩展实现高可用
上文中我们提到了水平扩展可以提高并发承载量，同时可以提高可用性，但侧重点不同。对于高并发，水平扩展表示我们可以通过增加机器/进程提高承载量。对于高可用，是说当机器/进程出现异常或者崩溃时，不会影响集群的整体可用。