开发中遇到的一些问题一

Posted 2020-10-10

问题记载

问题记载 1

1、做好各个功能的性能评估 1

2、 任务结构调整 1

3、缓存的充要条件 2

4、数据散列设计带来的问题 2

5、计算层和网关层的分层考虑 2

6、增加进程指定规则创建机制，原因在于： 2

7、排行榜，P25之前遇到的排行榜问题性能问题 3

8、P25大地图的设计 3

9、其他建议 3

 

1、做好各个功能的性能评估

P28-17年7月24日渠道瞬时导量2w+，导致服务器承载超过上限服务器卡顿无法正常游戏，玩家难以登录当天维护两次；

问题主要原因是，程序BUG+配置不够，具体如下：

a、数据库采用高效云盘且只有两个存储节点，由于存储节点相互备份性能甚至低于单节点，无法承载2W+的IOPS；

b、程序Bug，程序切换场景代码存在bug，有玩家在服务器出现了一直切换场景的BUG，该BUG给计算节点带来了较高负载；

c、最初现象是场景管理器处理业务超时，但不是主要原因，主要是上面问题引起。

解决办法：

a、扩展存储节点2台为4台，并切换为固态硬盘 ；

b、优化场景管理器，以阵营为一个单元进程在集群的各个节点当中；

c、增加中控，保证在遇到其他问题时可以立即开辟一个新的集群容纳新来的玩家（主要是最近登录服务器和充值消息的转发）。

 

2、任务结构调整

之前任务产生的计算量以及数据库访问频率较高，造成较多性能开销，做了如下优化

P28最初设计参照传奇挂机，任务数量为20个左右，所以直接在后端构建任务系统；

但后面任务数量一度扩展到500个左右，纯后端构建任务和成就系统，监听了游戏中所有的行为负载较高，

且多次读取数据库造成了较高的数据库IO和进程等待，所以重构了任务系统，前端推动和检测，后端验证结果CPU降低了不少。

 

3、缓存的充要条件

Erlang的缓存机制最常用的有Ets和进程字典，并依附于某个业务进程中，但分布式设计中需要尽量解耦，功能之间的联系

除了代码的直接调用就是数据之间的关系处理，我们希望的是节点尽量是无状态的。

数据尽量不缓存于业务节点，处理不当将会直接影响节点的可伸缩性和安全性；

但是有些情况有必须缓存比如，P28包裹产出和消耗巨大，给数据库带来了较高负载，不得不重新考虑业务的实时性，将包裹缓存至会话进程每5分钟检查是否有变化，有则存储否则退出时存储一次。

 

4、数据散列设计带来的问题

P28之前包裹、任务容器都是做的散列结构，一张索引表一张具体的物品表，优点是：

单独获取和操作指定装备比较便捷，一条数据变动产生的文件偏移量变化小IO少，

最危险的就是数据断键，造成索引和数据不一致，会导致很多垃圾数据的产生；

在P28上的问题是，游戏产出和消耗装备速度非常快，所以玩家进行熔炼N件的时候需要N次读取和写入，

我们即不能散列存放，因为操作频繁；又不能整行存放，因为一件物品变化就会读写整个包裹数据。

所以，后面将包裹数据缓存到会话进程上，数据结构用整行存储，因为频率变低了。

 

5、计算层和网关层的分层考虑

P28的网关节点和计算节点的业务是在一起的，而P25则是分开的，我们的原因在于：

a、负载问题：计算节点的均衡负载需要自行实现zm_pid_dist的回调，回调函数的实现不受保障；

b、网络问题：玩家受场景推动持续产生战斗行为和奖励等事件，通信率高，所以场景被设计在了网关层；

c、业务问题：除了场景没有较为密集高频率的计算以及大数据自动分析管理的需求。

所以我们让网关层和计算层运行在同一个节点上，业务交叉也方便些。

 

6、增加进程指定规则创建机制，原因在于：

P28有较多交互类活动是在不同进程运行但又需要数据共享，比如多张地图同时阵营活动；

在正常情况下zm_pid_dist出来的进程会分裂到各个计算节点，可是我们希望同一个阵营的地图进程创建到一台物理机上，

减少血量，伤害，排名等数据的跨节点同步；比如在某个军团挑战军团BOSS的时候，我们又希望同一个军团创建出多张军团BOSS的地图也在同一个节点上。

虽然提出了这个机制，其实也有它的应用面，但是我们做这个解决方案是错误的。

血量同步，数据同步最好还是放数据库的内存表，可以和策划沟通战斗的即时性问题，血量1s同步一次就解决了这个高频问题，所以这是一个过度开发。

 

7、排行榜，P25之前遇到的排行榜问题性能问题

1、之前实时排行榜采用的是分段处理保存，但是使用的是文件数据库来保存，效率低，对于排行数据变化频率比较高的那种排行榜，io的开销比较大；

2、目前的优化，目前优化后采用的是内存榜，在服务器初始化时通过排行榜管理进程初始化排行榜，然后排名的更新等都在内存中操作，降低了io的开销，提高了更新和获取排行榜数据的效率。

而P28这边的排行榜一开始就是以服务器为单位的进程存在集群的不同节点上。

 

8、P25大地图的设计

之前大地图采用的是滑到某块区域去获取数据库的数据，滑动快获取信息多，很容易造成性能瓶颈。

目前采用的场景进程的处理方案，在滑到某块区域后获取场景进程中管理的数据。

 

9、其他建议

a、唯一性提前控制，建议集群分段可采用cookie分段，在获取唯一ID时不同集群采用各自分段ID，否则平台BI将会出现相同数据;

b、大区概念，P28集群到现在仍然没有大区概念，只有服务器概念，服务器中有对应的渠道则该渠道玩家就可以进入。

因为P28有阵营概念就去掉了大区，但后面运营的时候对于服务器管理产生了诸多影响，比如自动合服的时候

不能识别是不是同一个大区的，采用相同渠道号的服务器作为同一个大区进行相关业务处理的；

c、场景计算，每帧推动的时候会选择目标，选择技能，根据战斗者属性计算伤害，可以考虑伤害计算好一次后不再计算，

后续继续采用这个数值。