游戏服务器：漫谈游戏服务器架构

　　【温馨提醒】文章内容仅供参考,海外服务器租用\托管方案,请咨询YINGSOO客服,24小时免费电话400-630-3752

游戏服务器

　　谈架构，先聊聊游戏业务特点。

　　1 、难点在于时间复杂度是以n ^ 2 进行增长的，以平方的级别增长的。具体业务展示为，如移动，一个人移动要通知其他人，n个人移动就是n * (n - 1), 以平方级别增长的。如世界聊本公司一致性要求高。这块是接近电商，金融的需求。物品因为某些原因，如bug, 突然多的，玩家会去刷，破坏游戏平衡，少了会导致用户流失。包括在数据丢失的时候，也得数据一致。毕竟有可能就是刚好冲了值，结果数据一丢，冲的钱没有了。

　　5 、数据安全这块，倒是不太重。允许丢失数据，正如社交能丢失聊本公司量比较小，一个服的数据，运行一个月导出来，可能就是几百m顶本公司一致性，其实在比较常规，一般采取事务处理解决

　　5 、数据安全这块，一般采取宕机写入数据，一般不会丢数据，除非是有硬件损坏，或者系统崩溃。一般不会丢，而且最多也只会丢5分钟数据。

　　6 、写数据比读数据多。这个其实也比较常规，一般采取缓存解决。

　　7 、游戏服务器的是有状态的，这个很多时候我们会采取热更新。以前甚至是直接把业务接口设计成插件，进行动态库重新加载的处理。还有快速重启这些策略

　　8、跨服，其实数据访问的问题，还有一致性的问题。

　　9 、开发效率，协作效率，上手难度。服务器框架采取很多都是面向^{[越南服务器租用]}接口+面向对象，以保证协作，以及开发效率

　　10 、线上查bug,一般就是日志 + core dump，还有一些监控工具，如top之类的。

　　11 、宕机一般就是安全关服，做各种数据保存。当然还有数据库宕机这些处理，业务拆分成分布式，进行进行分区容灾。

　　结果总体看来，数据的问题，线上查错，容灾，热更这些才是重点问题。而事实上在以前，会有网络问题，因为epoll跟iocp还没有出现，大家还用的select, 著名的c10k问题，所以架构上都会有网关的设定。还有就是这10年计算机的性能翻了很多倍，著名的摩尔定律了解一下，当年单机做1000人都是问题。现在都是不是问题。现在单线程 + 无阻塞队列，都能达到2000+，如果用上一些高频的机器，甚至可能达到5000人。以前很多的问题都不是问题了。

　　接着介绍一些架构具体的方案。

　　单线程 + 无阻塞队列

　　这个架构的重点在于业务线程不能有阻塞，其他io异步，一些重计算的，排行榜(堆排序)，聊本公司。当然有些类别可以做成无状态，如卡牌。不保存状态，就能实现快速重启，数据，逻辑分离好处多多。但并不是所有业务都能用，redis在单链接大概在2万qps，多链接确实能到10万qps。对于大部分业务是可以的，很多都是低频业务，但对于一些高频的，同屏100人用这个扛不住的。

　　分布式架构

　　这个架构的重点在于服务器拆分，一般按着业务，数据一致性进行拆分。

　　当然也会遇到一些问题

　　1 分布式数据一致性问题（最麻烦的问题，虽然说有通用方案，就是做分布式事务，采用最终一致性进行妥协，但很多公司的做法是不理，因为麻烦，通过把数据冗余尽量把分割的功能合在一起，策略采取先扣除，出问题，客服人工补）

　　2 调用链问题，因为功能割裂，有些时候问题查找麻烦（日志跟踪麻烦，因为功能割裂，日志分布在不同的服务器上）

　　3 运维的工作量剧增，或许需要开发一些额外的工具

　　4 单点问题不可用（网络不可用，机器不可用）

　　5 一些特殊的业务得做冗余设计，做缓存系统

　　其实可以明显对比，分布式架构要做要解决的问题会相堆比较多，所以有足够的人力才去做,所以这也是个考量的要素之一。

　　当然不同游戏类型，架构会稍微不一样，简单介绍一下

　　mmorpg 前面说过服务器拆分是依据数据一致性的，在mmorpg中，场景的数据是比较重要的，不像回合制，场景物体与人物，数据同步量比较大，做数据一致性比较麻烦，一般会把场景角色管理合为一体，如在场景捡一个物品，进入背包，人物血量同步,技能同步等。

　　棋牌游戏，压力会在于各种子游戏跟机器人上面，所以会采取按游戏拆分，每场游戏再进行数据同步，有业务的特殊性，网关规^{[数据存储服务器]}避攻击，规避监管。