漫谈游戏服务器架构

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

困难在于时间的复杂性N^以平方级增长。具体业务显示为，如移动，一个人移动应通知他人，N个人移动就是N*(N-1)，以平方级增长。比如世界聊天。所以很多游戏都采用了分服分线的策略。当然也有风险问题。目前用户成本居高不下，1000人的服务器成本上万。如果出现一些技术问题，一个服务损失点的人会损失几千或者几万，人数上升的风险太高。

2热点问题。具体业务展示为攻城战、帮会战等。规划的业务需求，人多热闹，尤其是设置场景的时候，人可以重叠。有点像12306306列车订票的问题，只是数量级不在一个级别。但是有一个问题是客户负担不起，不到100个手机同屏就不行了，网页flash只有200人在同一个屏幕上飞行，但客户端可以达到数千人。但是游戏服务器做千同屏问题不大。

3、响应速度高，基本需要50ms以下响应速度。因为网络延迟可以达到100ms,玩过lol或者王者荣耀，当延迟超过100时ms会有卡顿感，过了200ms,许多人不能玩。许多其他领域甚至可以达到第二级响应，但游戏不好。然而，并不是所有的游戏业务都需要高响应。高响应主要是在场景同步、移动和战斗中。玩家的响应速度会有最直观的感觉。然而，对于一些公会申请，这些响应需要更倾向于传统领域，1秒钟内可以接受，但最好是500ms当然，对不同游戏类型的响应速度有不同的要求。传说中的移动间隔是550ms,所以不超过200ms也可以，到500ms,就是一步一步卡住。当然，也许使用物品会有一点卡顿感。

4.数据一致性要求高。这是接近电商和金融的需求。由于某些原因，如bug,突然，玩家会刷，破坏游戏平衡，少会导致用户流失。包括在数据丢失时，数据也必须是一致的。毕竟，它可能只是冲了值，数据丢失了，钱就消失了。

5.数据安全不是很重。允许丢失数据，就像社交网络可以丢失聊天记录一样。但不能太长，最多5分钟，因为太长的玩家会觉得白玩。当然，最好不要丢失它，但面对灾难，丢失5分钟的数据真的是一件小事。在过去，在9377年，有1到2个月的数据丢失。不久前，腾讯云也丢失了其他公司的所有数据。关键是数据一致性。

6.写数据比读数据多。在所有业务中，移动占98%，一次移动必须记录坐标。因此，写作比阅读多。

7.数据量相对较小。运行一个月导出的服务数据可能是数百M顶天了，但这更多的是因为单服人数的关系。最后一件衣服平均有100人。

8.游戏服务器处于状态，重启玩家会掉线Bug需要快速修复，不允许轻易重启。因为写作比阅读更多，而且还有太多，所以一般需要做缓存，重启会导致缓存丢失。与某些领域不同，数据可以存储在数据库中，使服务器无状态，并随时重启。

9、跨服务、合服需求

其它需求与其他领域相似

1.开发效率、合作效率、启动难度

2、线上查Bug，容错能力

3.停机，容灾

现在开始谈解决方案

1.事实上，计算时间复杂性的问题通常可以通过同一屏幕广播和集中分发来解决。它甚至可以不处理，因为它通常受到客户端的限制，用户数量没有达到那个位置。当然，即使是一定数量的用户（至少数万个单一服务）也需要考虑这个问题。当然，解决这个问题的根本方法是建立一个集群，也就是说，同时，几台机器携带相同地图的场景操作（当然，这里也有一些坑和问题，最高上限估计为100万，因为带宽先爆炸）。但最重要的是成本问题。互联网创业的基础是边际成本为0，或者用户数量接近0。然而，这样，边际成本将越来越高。因此，基本上采用分服分线策略

2点问题，业务需求，无法解决。

3.高响应，一般游戏至少30帧，每帧30帧ms。但服务器真的不需要让响应时间达到30ms,一般玩家一个动作是10帧以上，至少8帧，动作结束前响应。100ms以下基本ok,除了一些需要高精度处理的，比如王者荣耀。

4.数据一致性，其实比较常规，一般采用事务处理

5.数据安全一般是停机写入数据，除非硬件损坏或系统崩溃，否则一般不会丢失数据。一般不会丢失，最多只会丢失5分钟的数据。

6.写数据比读数据多。这其实比较常规，一般都是缓存解决。

7.游戏服务器处于状态，我们经常采用热更新。过去，业务界面甚至直接设计成插件，以重新加载动态库。还有快速重启这些策略

8.跨服务，实际上数据访问和一致性。

9.开发效率、合作效率和启动难度。服务器框架中的许多是面向接口 面向对象，以确保合作和开发效率

10、线上查Bug,一般是日志 coredump，还有一些监控工具，如top之类的。

11.停机一般是安全服务，做各种数据保存。当然也有数据库停机的处理，业务拆分成分布式，分区容灾。

总的来说，数据问题、网上查错、容灾、热是关键问题。事实上，在过去，会有网络问题，因为epoll跟iocp还没出现，大家还用select,著名的c10k问题，所以会有网关设置在架构上。此外，在过去的10年里，计算机的性能翻了很多倍。著名的摩尔定律知道，单机1000人是个问题。现在都是问题吗。现在单线程 可以达到2000 ，没有阻塞队列。如果使用一些高频机器，甚至可能达到5000人。以前很多问题都不是问题。

然后介绍一些具体的架构方案。

单线程 无阻塞队列

该架构的重点是业务线程不能被阻塞，其他的IO异步，一些重计算，排名(堆排序)，聊天(ac自动机)等需要特殊算法进行优化，或分布式架构，拆分出来。

当然可能会遇到一些问题

1.无锁编程(不必要，可以简单的队列处理)

2.多线程死锁问题

3.跨服务会比较麻烦，因为架构耦合比较严重般建立新的服务作为跨服务，进入跨服务数据同步过去，退出跨服务，然后反向同步数据

4.单点问题，一旦不可用，就是整体不可用

这个设计的目的是设计的目的是实现服务器无状态，存储状态redis在内部，主要的游戏服务器基本上是状态，需要保存一些状态数据。当然，有些类别可以是无状态的，比如卡片。不保存状态，可以实现快速重启、数据、逻辑分离的好处。但并不是所有的业务都可以使用，redis单链接2万左右qps，多链接确实可以达到10万qps。对于大多数业务来说是可以的，很多都是低频业务，但是对于一些高频业务来说，100人在同一个屏幕上无法携带。

分布式架构

国际象棋和纸牌游戏的压力将在于各种子游戏和机器人，因此将根据游戏进行分割，每个游戏将进行数据同步，具有业务特殊性，网关避免攻击和监督。

事实上，架构设计更多的是为了解决问题，比如一些流行的微服务。事实上，它主要是为了解决在大量人力的同时完成一个项目的问题。当沟通成本急剧上升时，合理拆分，降低沟通成本。

这是一篇总文章，因为这些细节的解决方案可以成为一篇文章。空间有限。细节将在后面开始讨论。

数据存储策略

mysql我们需要了解的技术细节

mysql一些高可用性方案

redis我们需要了解的技术细节

游戏业务中常用的算法

lua热更新思路

地图，场景同步方案

跨服实现

数据一致策略，事务处理

构建自动化测试

编码上的一些小技巧(防死循环)

一些有趣的设计架构(多租户架构)

架构方案更详细（mmorpg等）

选择微云网络租用游戏服务器！微云网络已成为中国最大的海外服务器IDC服务提供商、服务器、数据中心解决方案发展成熟，主要行业上市企业也热衷于与微云网络合作，节省忧虑、麻烦和时间。微云网络为许多企业提供最安全的海外游戏解决方案、游戏数据安全解决方案、游戏服务器配置安全、游戏服务器安装方案。