游戏服务器常见问题的解决方法分享

游戏服务器常见问题的解决方法分享

在游戏开发设计中，人们经常会遇到一些瓶颈，由此产生的bug会危及所有游戏的质量。

过压保护、集群、网络服务器通信、高并发机型选择等问题是中小型精英团队常见的瓶颈。本文分享一些权威专家在整个走访过程中提到的解决方法，希望能给大家提供一些帮助。

问题一:游戏玩家登录时，获取好友的信息内容，但好友服务项目繁忙导致登录不成功。

解决方案:

1.在分离的关键路径上启用非关键访问，减少了事务管理步骤，防止了附近服务项目的异常阻塞登录。

2.超出解决问题能力的服务项目熔断机制，快速失效，避免塌方。

3、按照客户保护事务管理，避免兔子单客户恳求屏蔽对普通用户的伤害。

问题二:高压测量和并发着陆给redis造成了很大的工作压力。

解决方法:有大量的redis数据分析表。一个事务管理会引起几个redis请求，小表合并成大表。

Wade:一般网络服务器进程的管理方式都很简单，很多还是使用环境变量的静态数据机构。另外，通常缺乏进程间通信的方式，也没有消息队列分布式数据库的应用，甚至用Redis作为通信组件应用。为了提高集群管理方法的自动化技术水平，应用ZooKeeper是一种比较常见的方式。

ZC:redis一般作为运行内存缓存文件，不适合在redis中存储重要的数据信息。其数据信息安全系数还不如普通DB。在整个应用过程中，还要参考性能基线， *** 控浏览频率和总流量。

问题三:外部服务项目有延迟，导致激活的工作流出现卡屏。

解决方案:在业务流程端完善缓存文件:玩一个朋友msdk+近期人物角色id+人物角色信息内容。

韦德:很多精英团队都很重视过压保护的缺失。通常情况下，只有在顶级手机客户端这一侧，才会有线程或应用数量的限制。但是对于几个内部进程，比如浏览数据库查询进程，并没有过多的负载维护。因为游戏中有很多进程，所以三层交换机通常做的很少，大部分都是根据情况所属的进程来共享和解决请求。

Zc:注意缓存文件和降级解决方案。服务外部平台数据信息，尽可能缓存文件，提升浏览体验。当发现外部服务项目异常或自身出现负载风险时，应对服务项目进行降级。

Jovi:在rightsJovi:msdkmidas服务平台等api连接工作中，游戏业务流程可以创建保护层，专业解决这一需求，避免兔子过多入侵游戏逻辑， *** 控起来也容易很多。

问题四:运营和线上客服网点更改游戏玩家的数据信息，会导致所有正常游戏的数据信息被回写的市场竞争。

解决方案:应用类似的电子邮件系统来更改数据信息。

Zc:在多线程开发的设计中，服务水平往往会因为线程池耗尽或者线程死锁而降低。建议根据业务流程的需求对线程池进行有效的分类。不同的业务流程有有效的负载分配，不容易相互影响。非关键步骤必须推迟或多线程，以防止重要步骤被卡住。

此外，有效的线程实体模型可以合理地减少线程之间的市场竞争。真正要在市场上竞争的资源，要统一有序地锁定在台阶的入口处，防止整个逻辑过程中的随机嵌套和循环锁取市场竞争。此外，为锁添加一个请求超时时间，以防止业务流程终止。

Jovi:保证只有数据信息可以同时更改，有利于防止数据信息市场的竞争。提出方案时采用CQRS法，用单独的数据分析表和服务项目记录恶性事件，汇总成单个变更服务项目实施。

Wade:高并发编程是服务器端最常见的问题，通常采用多线程或非阻塞的方式处理。对于适合多线程的纯自然语言，比如JAVA，很多开发者倾向于多线程。好处是编码写起来比较方便，但是需要对锁定各种目标的实际 *** 作保持清醒的头脑，或者熟练应用类似java.util.concurrent这样的特殊多线程工具库如果应用是非阻塞的，好处是不容易锁定，但是代码被切割到每个回调函数中，可读性很差。因此，一些精英团队会使用“协同流程”或承诺等特殊工具来缓解这一问题，但这也引入了很多多样性。

下面详细讲解一下游戏服务器架构中的生产调度架构，方便大家理解。

a)单进程游戏网络服务器

一个非常简单的游戏网络服务器只能有一个进程，就是单点。如果这一进程被撤回，所有游戏将在全球范围内褪色。在这个过程中，由于必须解决高并发的手机客户端的数据文件，所以选择方法有很多种:

[图-单流程生产调度实体模型]

相同线程-动态多线程

每个客户端应用程序被接受，一个线程被创建。这个客户端应用程序通常是指手机客户端的TCP连接，这样每次启用从socket加载或写入数据文件时，都可以应用阻塞方法，编号直观简单。有多少游戏手机客户端的连接，就会有多少线程。但是这个方案也是一个显著的缺陷，也就是说网络服务器非常容易造成线程多，对于运行内存来说不容易 *** 纵，线程转换也会导致CPU的性能受损。更重要的是，多线程下读写同一条数据信息的能力必须解决锁的问题，锁会使编码更加复杂，导致各种死锁bug，危及网络服务器的可靠性。

相同线程-多线程池

为了节省线程的创建和释放，创建了一个线程池。当每个客户端应用程序被创建时，它应用于线程池来解决线程应用程序。当客户端应用程序完成时，线程不会退出，而只是将应用程序“释放”到线程池中。线程池可以很好的控制线程总数，可以避免客户暴涨对网络服务器连接造成的冲击，造成系统排长队。但是线程池本身的维护是非常复杂的，必须严格执行“应用处理”和“释放”线程的启动标准，否则会出现线程泄漏，线程池会被耗尽。

多线程-单线程/协程

在游戏制造业中，为了获得高性能，选择Linux的epoll作为互联网API是一种常见的选择。网络服务器进程中最常见的阻塞激活是网络IO，所以选择epoll后，所有网络服务器进程都会越来越完全的无阻塞启用，所以只需要一个线程。这就彻底消除了多线程的锁问题，也简化了高并发程序的编程难度系数。但是“全部启用不能屏蔽”的约束力就没那么好遵循了。比如一些数据库查询API被屏蔽；另外，单个进程和单线程只使用一个CPU，所以在当今多核多CPU的网络服务器中，无法灵活使用CPU资源。多线程编程是基于“回调函数”的方法，会造成定义很多回调函数，一个步骤的逻辑写在几个不同的回调函数里，看文章做编码很不好。-对于这种编号问题，协程可以很好的帮助，所以现在比较时髦的是应用多线程+协程的组成。无论如何，多线程单线程实体模型因为性能好，不需要高并发逻辑思维，仍然是现在很多精英团队的首选。

多线程-修复多线程

它是一种基于多线程和单线程实体模型的实体模型。这种实体模型一般有三种类型的线程:主线程、IO线程和逻辑线程。所有这些线程都以完全多线程的方式运行，它们根据无锁消息队列相互通信。

b)多进程游戏网络服务器

多进程游戏网站服务器，这是从性能问题的要求出发的。因为在单进程框架下，会有承载能力的极限，越复杂的游戏，单进程承载能力越低。因此，开发者必须提高进程限制，以支持更复杂的游戏。

一旦步入多进程之路，开发者还发现了多进程系统软件的一些其他好处:可以利用多核CPU的工作能力；使用服务器系统的特殊工具可以更仔细地监控 *** 作，并且更容易执行灾难恢复和备份解决方案。多进程系统软件的经典实体模型是“三层架构”:

在多进程框架下，开发人员一般倾向于将每个控制模块的功能独立设计为一个进程，然后应用进程间通信来和谐地解决细节逻辑。这种概念是典型的“管道和过滤设备”架构设计概念——将每个进程视为一个过滤设备，客户发送的数据文件流经由几个过滤设备组成的管道，最终得到详细的解决。因为应用了多个进程，所以最好使用单个进程和单线程来构建其中的每个进程。就游戏软件开发而言，结构清晰简单，可以获得更高的性能。

[图-经典三层实体模型]

虽然好处很多，但多进程系统软件还有一个必须注意的难题——数据存储。因为这样可以保证数据的一致性，所以存储过程不能分成几个过程。即使关系数据信息被分成数据库和表，它也是复杂的，并且取决于业务流程的类型。而如果单独的逻辑求解过程无法承受负载，由于其运行内存中的数据信息无法拆分共享，开发者无法并行扩展一个特殊的业务逻辑。他们会选择让业务逻辑流程无状态化，但这加重了存储流程的性能压力，因为每次业务流程求解都要去存储流程获取或加载数据信息。

除了数据信息的问题，多进程架构还产生了中国维和人员开发设计的一系列问题:首先，它意味着所有系统软件的部署更加复杂，因为必须连接和配备几个不同种类的进程，因此必须管理许多环境变量；其次，因为有许多进程间通信，所以必须定义的协议总数也是巨大的。在单个进程中处理一个函数调用的问题，要在多个进程中定义一套征求和回复协议，这就导致了所有源代码 *** 作规模的扩大。最后，所有的系统软件都被分解成许多短小精悍的代码。不掌握整体结构，就无法知道一个详细的工作流程是如何解决的，这就使得阅读文章和编码的工作交接成本极高，尤其是在游戏行业。因为工作流程变化非常快，基本上没有人能完全掌握修改后系统软件的内容。

天地数据拥有超过15年的游戏管理经验。全球有50+CN2顶级互联网和1300+CDN连接点，包括但不限于香港特区、英国、日本、日本、马来西亚、新加坡等10个国家，可即时接入CN2快线。没有理由不备案空，并展示了智能系统DDOS安全防护更新、三层交换机升级、集群服务项目查询及数据库提案、CDN连接点合理布局改进等一系列优质服务项目。，从而为合适的公司打造专业的游戏解决方案，牢牢把握客户，合理布局世界。。