1、做好各个功能的性能评估 1
4、数據散列设计带来的问题 2
5、计算层和网关层的分层考虑 2
6、增加进程指定规则创建机制原因在于： 2
7、排行榜，P25之前遇到的排行榜问题性能问題 3
1、做好各个功能的性能评估
P28-17年7月24日渠道瞬时导量2w+导致服务器承载超过上限服务器卡顿无法正常游戏，玩家难以登录当天维护两次；
问題主要原因是程序BUG+配置不够，具体如下：
a、数据库采用高效云盘且只有两个存储节点由于存储节点相互备份性能甚至低于单节点，无法承载2W+的IOPS；
b、程序Bug程序切换场景代码存在bug，有玩家在服务器出现了一直切换场景的BUG该BUG给计算节点带来了较高负载；
c、最初现象是场景管理器处理业务超时，但不是主要原因主要是上面问题引起。
a、扩展存储节点2台为4台并切换为固态硬盘 ；
b、优化场景管理器，以阵营為一个单元进程在集群的各个节点当中；
c、增加中控保证在遇到其他问题时可以立即开辟一个新的集群容纳新来的玩家（主要是最近登錄服务器和充值消息的转发）。
之前任务产生的计算量以及数据库访问频率较高造成较多性能开销，做了如下优化
P28最初设计参照传奇挂機任务数量为20个左右，所以直接在后端构建任务系统；
但后面任务数量一度扩展到500个左右纯后端构建任务和成就系统，监听了游戏中所有的行为负载较高
且多次读取数据库造成了较高的数据库IO和进程等待，所以重构了任务系统前端推动和检测，后端验证结果CPU降低了鈈少
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大地图的设计
之前大地图采用的是滑到某塊区域去获取数据库的数据，滑动快获取信息多很容易造成性能瓶颈。
目前采用的场景进程的处理方案在滑到某块区域后获取场景进程中管理的数据。
a、唯一性提前控制建议集群分段可采用cookie分段，在获取唯一ID时不同集群采用各自分段ID否则平台BI将会出现相同数据;
b、大區概念，P28集群到现在仍然没有大区概念只有服务器概念，服务器中有对应的渠道则该渠道玩家就可以进入
因为P28有阵营概念就去掉了大區，但后面运营的时候对于服务器管理产生了诸多影响比如自动合服的时候
不能识别是不是同一个大区的，采用相同渠道号的服务器作為同一个大区进行相关业务处理的；
c、场景计算每帧推动的时候会选择目标，选择技能根据战斗者属性计算伤害，可以考虑伤害计算恏一次后不再计算
后续继续采用这个数值。
