如何设计属于本身的游戏服务器（二）

不少游戏都在花费大篇幅讲解网络模型，其实，这些对于你而言，彻底没必要关心，现有的模型一大把。就好比PSS，你用它就能够忽略网络IO模型，直接负责处理到达的数据和如何回应就好了。
那么，咱们来讲说游戏服务器的一些细节。
以端游为例，如今的端游能够说各类花哨，各类副本，公会战，任务，锻造，跑商等等等等。。系统繁多。
可是请静下心来，拨开那些层层迷雾。
其实游戏服务器没什么神秘的，就几个专业的算法可能比较耗一些功夫，好比，AOI，好比，寻路，好比，脚本。
先不要去想这些实现手段，首先要知道，咱们有什么武器？
不管任何游戏，都分为两种消息，一种是客户端主动提交给服务器的，一种是服务器主动下发给客户端的。简单的来讲，无外乎，一去一回，一回一去，一去，一回。
一去一回，就是客户端主动发起一个事件，须要获得服务器的回应。
一回一去，就是服务器有事件发生了，须要通知客户端。
一去，客户端只是通知服务器一个事件。不须要回应。
一回，服务器通知客户端一个事件，不须要回应。
很好，先明确这个概念，也就是，服务器和客户端之间的通信，是一种或者几种事件机制。
网上一些说游戏服务器的文章，说每秒吞吐几万个数据包如何如何性能了得，我很想问问，实际的游戏服务器，你真须要这么大的服务器吞吐量吗？
固然，你能够说，像Dota，星际那种实时对战游戏，对数据包有及是毫秒级的要求，毕竟人家讲的是DPS。可是，我想说的是，大多数游戏，根本不须要这么多的数据包吧。
不少时候，设计是能够优化的，若是我是一个玩家，1秒钟内在地图点击了10个地点，若是控制的小人都去那些地方，光服务器和客户端来回耗时就会不少。先不谈网络优劣的问题。问题是，这些数据有必要服务器去处理吗？
（1）必须先明确，什么是无效的数据和事件。
对，什么是无效的数据。无效的数据很空泛，其实从用户行为分析，你能够分析出用户在你的游戏中，哪些是属于无效操做。客户端主动屏蔽这些无效操做。好比，1秒钟我换了10个方向，那么我只须要取得最后一个防线便可。也就是前9个我彻底能够忽略。固然，客户端须要处理一下这为展现。再好比，我反复的打开了商店界面，由于商品在必定时间内是稳定的，那么彻底能够过一段时间同步一下商店数据便可。不用每次都发送请求。
不过从实际运行来看，并非说客户端屏蔽了这些无效操做就能够了。服务器同样要作这些动做，由于你没法约束数据包行为。或许外挂，特殊状况，会有垃圾数据包到来。
就比如，你把服务器看作一个餐厅，进来一批食客，其中保不齐有周围餐馆派来砸场的，你的厨师就那么几位，有些人故意点了一大桌子不吃，害的你的厨师忙死，却让真正想吃饭的食客等不及而离场，这明显是得不偿失的。因此，你的服务器须要一个经验丰富的"侍者"，它能够分辨食客的点餐餐单，那些是有明显问题的，好比，有i一个食客连续点了10个宫保鸡丁，你就要看看这个食客究竟是要干什么。
服务器的这个"侍者"，就是要对客户端上来的各类"餐单"(数据包)进行初步过滤，起码，不能让那些明显处问题的餐单来占据你的服务器资源。
从设计的角度来说，我能够对某一个用户的数据包进行归类，某一类数据包不能短期出现屡次。若是出现了且非要回复，只取得在这段时间内最新的一个便可，其余的同类数据包丢弃。
我这里要讲一个设计关键原则，就是必定要保证优质的游戏玩家享受最好的服务，而那些质量差的玩家，不多会为你的游戏多付费，因此，想办法保证一切优质客户很重要，服务器的资源也应当倾向于此。
（2）那些是必须如今返回的，哪些是能够等一会再返回的。
不少网络讲游戏服务器的文章，更加更关注的技术的实现细节，而实际上，咱们跳出这些繁复的代码。仔细分析一下？哪些是 "当即"和"暂缓"。
仍是拿餐厅举例，通常人气火爆的餐厅，大多不会一个客户点一个菜马上抄一个。抄完了在看下一个餐单。
而是，会等那么一小会，看这一小会会不会有相同的餐单到达，一锅烩，一块儿出盘。
别小看餐厅的学问，好好的和他们学习，你会学到很是多的服务器设计知识。并且，好的餐厅每每能教你怎么作一个伟大的服务器。
那么，你看，这些餐单，实际是能够"等那么一会也没什么大问题的"。
而有些则是必须立刻返回的，好比，食客下了餐单，你必须交给厨房之后迅速的告知食客，你的餐单已经到达了厨房。
拿游戏中的一个实际功能来讲，玩家发出一个"行走"指令，实际上，客户端已经能够行走了。服务器只要返回一个收到了便可。只要定时计算服务器和客户端的玩家点位是否匹配便可。有差距拉回来。
而对于服务器，彻底能够等那么一等，好比，等1秒，这1秒钟全部的玩家行走指令都收齐了，一个定时器一口气算出来。
或许就有那么讨厌的玩家，连续1秒钟换了3,4个终结点。
换个话说，有哪些餐馆讨厌的食客，刚下单就要换菜品，犹豫不决，若是餐厅没有这个"缓冲"时间，那么作出来的菜谁去消费？明显是浪费食物。（浪费服务器资源）
还有就是，游戏中的交易，必须时时反馈，交易成功了仍是失败了，必须第一时间让玩家知道。
餐馆也是这样，结帐的时候，食客提出刷卡，若是服务器员说你等会，等到一波食客一块儿刷，人家不骂你才怪。
因此，从设计上来说，要学会细分这两项，仔细想清楚，会给你的服务设计带来很是好的体验提高。
（3）如何规划数据流
仍是拿网上的文章来讲，不少文章在游戏服务器上推崇多线程。
多线程，对于初学者总以为会很快，而当实际使用的时候，老是发现各类数据须要再不一样的线程里同步的问题，形成大量的数据锁，代码复杂了不说，本身估计之后都难以看懂。
因此，这里要说，组织多线程是一门学问。
仍是那个餐厅。
我有10个桌子的食客，其中6个点了甜点，有4个点了鱼肉，有7个点了小吃。
若是让一个厨师去作这些菜。确定会慢的出奇。
看看现实中是怎么解决的？有甜点师，有配菜师，有几个大厨，分别应对不一样的菜品。同时去作，各自互不干扰。作鱼的不用知道食客点了多少甜品。
那么，游戏服务器是怎么表现呢？
我有一个玩家进了一个场景，那么理论上，一个场景内，只有这个场景内的玩家会对他产生影响。别的场景均可以不用知道这个玩家的存在。
那么，若是把这个场景看作一个厨师，那么"玩家"实际就是一个个餐单。不一样的厨师去料理不一样的餐单便可。菜能够同时上，也能够一个个上。
实际上，90%的多线程数据锁，是彻底能够用这种或者那种数据模式去解决的。

大天然教会了咱们如何生存，也教会了咱们，如何用这些规则造福别人。因此，不少程序设计上很难的问题，实际你的生活早就教给了你解决方法，关键是，要学会去发现，去思考。