如何设计属于自己的游戏服务器（二）

freeeyes

很多游戏都在花费大篇幅讲解网络模型，其实，这些对于你而言，完全不必关心，现有的模型一大把。就比如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%的多线程数据锁，是完全可以用这种或者那种数据模式去解决的。

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

4176244

真正要把服务器写好挣钱，还真的要学学VIP这种服务，花钱的却是是大爷，要好好服务。