继上面的第一篇文章，没看的可以翻一下。还是进程数量多的问题？

副本问题怎么解决？服务器该如何设计？

按照他们这个做法是副本与场景都是地图，所以就造成了下面这样的问题。假如，我有1万人的在线数量，那么就需要开100个进程出来维护这1万人，这还只是在场景中； 如果，玩家要打副本，那么，按照这个设计，就需要一直开进程。一个人进副本，也是启一个进程来维护你这个玩家。2000人进副本就是2000个进程，这个开销程度可想而知。副本最多可以4人组队情况下，同时进入，这也需要500个进程。这里就产生了大量的服务器资源的浪费。

所以，他们这里的服务器解决策略是什么？

把前期推图的这些副本做出成了离线副本，就是单机的意思。进去打怪战斗的逻辑在客户端完成，装备掉落，任务完成由Logic服进行了校验。所以，他们的客户端是有战斗的， 不知道这个防作弊机制是怎么样的、关键数据，由Logic进行了校验，记录你通关的副本，奖励等等。这样确实，减少了大量的服务器进程数量。也确实解决了服务器压力的问题。但，ta这是不能组队的，不能与玩家互通的。

世界boss战，跨服如何解决？

上面提到，副本是单机，离线的。随着时间推流，玩家早晚要进Boss战的，跨服副本等等。所以，这里怎么解决？

这里直接使用了场景服务器集群，不亏是大公司！按照下图这样的计算，这一组就是八个，八个按照最多人数那样算，就是可以进行800人的战斗。当然，ta不可能放那么多人进去的。总需要留一些空余，做其它的事情，保证副本的流畅性。

性能优化！重中之重

关乎老板的钱包的多少的切身问题。合理的优化能让你省去一半的服务器开支。

这里的优化思路着重分为了两部分： CPU与内存 ！还是那句DS真不是你想用就用的。

CPU的优化细节，最初的设想，就是只同步自己。按照他们那个设计， 玩家最初的出生点在一个寂静的村庄里，没有人。这里就合理的优化掉了。

后面的这些开发的业务逻辑上来了，不仅有人偶，还有宠物，都需要跟随。这里的优化是直接去掉，不同步。只有当真正需要调用到才同步

这里还接入了UE的插件，来把场景中的Actor分组出来，然后优化。网格同步其实就是AOI，只能看到视野范围内的。

摄像机背后同步是什么意思？  就是 玩家视野前后的同步频率不一样，前面的可能30帧每秒，后面可能就10帧。

不移动还用同步吗？？？用的，这就是DS。 所以，后期优化 直接改为了玩家不移动就不在同步。

这差不多就是属性同步上的优化策略。

物理计算为什么要优化？

这是因为DS服务器的前后端代码，放在了一起，所以前端跑动画，后端也跑动画。这无关紧要的放在服务器上，徒增了CPU计算负担！！ 后面还是给分开了。前端是前端，后端是后端。

业务需要的时候再计算？ 什么意思？ ta这个游戏有人物抬枪射击的动作，射击需要计算射线，朝向对吧！所以，关键的动作，在这里同步一下就可以了。其它的乱七八糟的头发，装饰在前端表现就行了。

这个移动同步前面说过了。DS服务器是可靠的服务器，UDP可靠！降低频率及降低了校验频率，节省带宽！

FindFloor 是UE中的一个查找地面组件。关乎玩家角色，是否在地面上行走，斜坡上还洼地里。玩家的移动会一直不断的更新这个函数，不移动也更新的话，就显得多余了。直接降低这个函数的更新频率。

关于服务器设计特殊移动的一点思路与见解

借用一下B乎的文章。如果是单机，那就不用考虑这些了。

这就有点取巧的意思了。借客户端的优化思路，优化服务器。服务器默认按照，30帧每秒的一个频率再更新。如果CPU使用率超过百分之80会怎么样？你的手机负载超过80%会怎么样？会降频，减少计算数量。俗称掉帧！ 这里的服务器也按这个策略，用来保证服务器的能够流畅的运行。

内存优化

最开始一篇的文章中，我们提到，他们的DS场景服务器是集群的，他们这一组服务器，是在同一台服务器上，所以能开出共享内存。用Linux下的fork函数去fork进程，同时又使用上了Copy-on-write （写时复制），当，有玩家触发写任务时，copy一个副本出去给ta改。不是什么新鲜事物。

优化完毕！总结，

所有，这一切，优化完了 服务器CPU与内存节省了约50%。所有的优化，都需要满足业务需求！

更新维护

在线更新，不停服，其实就是lua热更！！只适用于小规模的活动更新。大型的改动还是需要关服更新。

调度策略

这是我认为这里学到最有用的一点，通过这个调度策略，可以很有效的规避了服务器内存泄漏的等严重的服务器bug，当，场景服中存在bug，在线更新解决不了时，这个时候的做法是，把新修改的版本，布置了一个新的集群上去，这个时候的Logic服会根调度策略选择最新的版号。 这排序一下就行了。 通过这样一个轮询的机制，就把坏的版本，换了下来。客户端也不用等待服务器的开服。

这样的思路其实可以做很多事情。比如开发了新版本，新内容， 也就把滚动更新实现了。

其它挑战

时间精度

DS服务器使用了float类型，描述时间，在服务器长时间启动不关的情况下，float类型误差会越来越大，导致移动位置不准确。这里的解决是，扩充double类型。

同步顺序

这个意思是说，当场景服务器把各个actor下发时，会出现不同步的情况，下发的时序是不保证的属于有了就发这种，信息对等不上，所以这个时候就在业务层于场景之间加了一层代理，来保证同步顺序是一致的。当，都到达时，才发送，没有一直等在哪里，缓存队列那种。

无缝切图

这 不说了 懂得都懂，不懂看文档。

使用DS的一点建议

到这里，算是全部讲解完了。

这算是把后端这一套的完整的从开发到上线维护的所有细节都教给你了。

剩下的就是去执行的事情了。

你问我代码怎么写？ 那我只能说，框架摆在眼前，剩下就垒砖的事情了。