3D 游戏的万人同屏技术详解(2)

[gantleman]

全文地址
https://zhuanlan.zhihu.com/p/195059458

在<使用 redis 实现 5 万人同服的'相位技术'>中我介绍了基于九宫格和相位技术的空间管理技术。这里我们也要借鉴游戏服务器中“服务”的概念。可能有些同学没有接触过游戏服务器，对服务的概念不是很熟悉。服务可以看做是一个独立的线程环境。这个线程监听着一个消息队列。其它的服务可以发送消息给他。这种方式在服务器开发中的 go 语言，erlang 语言，skynet 框架中被广泛应用。消息队列保证了服务所创建的数据是私有并且多线程安全的，只能通过消息通讯的方式进行修改。服务的概念为多线程下使用数据的安全问题提供了保护。通过消息通讯建立了在多线程下的秩序。但这种方式在客户端使用的并不多。各种服务的框架也都是在服务器端使用的多。

客户端使用多线程开发管理 1 万多个线程将会是一场噩梦。而管理 1 万多个服务对技术水平要求也还是比较高的。针对客户端没有多线程的服务框架问题，我开发了 pelagia 框架。借用“服务”的概念来管理客户端多线程。通过内嵌 kv 数据库和预判以及服务私有数据的概念彻底消灭多线程死锁和依赖的问题。因为只有解决多线程的安全问题。才能进一步思考如何优化通信和计算以及存储的平衡问题。安全问题不解决所有的优化问题就会是空中楼阁。

全文地址
https://zhuanlan.zhihu.com/p/195059458

[gantleman]

@cs8425 做个简单的算数题，12 个人同屏，其中每个人以每秒 60 次的频率给其他 12 个人发送广播。这个广播的数据包括移动，射击，技能。那么每秒就是 12 乘 12 乘 60 次共 8640 次服务器数据提交。假设服务端只有一台 redis 处理数据。那么理论极限每次可以每次提交处理 10 次数据请求。所以是不是我数学不好，我没想明白为什么 redis 性能不能满足你 12 人 pvp 的数据处理需求。

[cs8425]

@gantleman #61
先不题游戏(尤其是技能造成)的复杂度没你想的那么简单
光你这算法就能得证"毫秒级"是不够的
不知道您是否真的有去算过?
1 秒 /8640 次 ~= 0.116 毫秒 /次 (~0.116 ms/req)
也就是一次请求要在 116 微秒内完成
已经是"微秒级"了
再加上还有计算要做
"毫秒级"是肯定不够的
我还是不懂为啥你一直认为 "redis 性能" 可以直接跟 "内存操作"放在同一个等级....

[firefox12]

@cs8425 60HZ, 100HZ 这么高的同步吗？ 那么一台服务器能拖几个用户，pps 够用？

[LennieChoi]

现在游戏服数据都放 redis 上了吗 😳，那光保证数据一致性问题就要费好大劲吧，还要加个事物吗，除了服务器变成无状态可以分布式负载计算，还有减轻内存负载，想不到数据放 redis 里有啥好处。如果说防止服务器意外崩溃，可以使其他服继续读取 redis 继续计算，那么内存缓存的服务器也有方案啊，只不过是 A 服崩了，把 A 服里的数据重新负载到 B，C，D... 等服继续计算，都是负载均衡策略。如果说玩家数据和某个服是强绑的，某个计算必须在某一个服执行，那放 redis 也解决不了这问题啊

[gantleman]

@LennieChoi 以前也是放到缓存服务器上，不过都是各个公司自己写的。游戏数据远不比银行或互联网，可以说 99%的数据都是垃圾数据。没有那么严格的一致性要求。用户回档补些金币或礼包就可以了。过去 C++写的服务器意外崩溃很多，现在都是脚本语言，已经很少担忧服务器崩溃的事情。

[ConradG]

这个题主就真的很值得……block

[swulling]

@cs8425 看起来是 lz 常写页游服务器，不理解 FPS PVP 服务器的技术。

其实两种服务器的技术要求可以说完全不同。

[gantleman]

@cs8425 redis 的 1 秒 /10 万应该可以覆盖 1 秒 /8640 次吧。起码差着一个数量级呢。所以肯定不会是 redis 性能不够。没错 redis 需要网络，需要解析命令，然后是使用 map 存储。起码比内存操作慢了 100 倍。如果 redis 这种基本的分布式组件都不能满足需求，哪游戏开发就不能用分布式了。mysql 都不能用了，因为性能太差。多线程有锁的开销必然也比内存操作慢。哪多线程也不能用了。文件 io 比 redis 更慢了也不能用了？你看单线程内存操作最快了，游戏服务器开发用单线程最好？

[k9982874]

同意前面老哥说的，redis 不是瓶颈。
redis 可以用，但是数据直接放内存更佳。

[Moepo]

@ConradG 楼主提交了源码，写了源码的介绍文章。虽然认知有差，交流不是很顺畅但是也引出了一下我觉得很受用的讨论。整个楼层都在就事论事，也没有人身攻击和贴吧回复出现。我觉得这就是每天应该出现的再正常不过的帖子。
按照您的说法，看了您的回复和新帖，我觉得您更值得 10 倍被 block

[ConradG]

@Moepo 原来 block 还是能被 @的

题主故意混淆“同屏”和“同服”。
题主故意规避问题的适用场景。
题主在尝试用一个高延时的点对点的消息通讯架构来做实时性要求极高的网游服务端逻辑计算，避而不谈网游中重要的群体状态管理如何在这样一个弱一致架构下实现，同时对时间开销也含糊其辞。
我同意 LS 的一些意见，这个架构可以拿来写部分页游。但是 LZ 这系列文章的开头又偏偏举了 Aion 和 Eve 两个典型 MMORPG 端游的例子。
题主对于网游中重要的数据一致性的认知非常神奇。如果数据出问题都是回档发礼包，第二天可能是运营提刀上门，第三天估计就是资方提刀上门了。

再结合题主的过往文章。我觉得到此为止，大多数人足够判断题主是单纯的认知有问题，还是揣着明白装糊涂而有其他目的了。

[cest]

@Moepo #70 软件工程师碰到社工工程师就是战
结果就是如了对方的意, 让他红了
再遇到你这程度的猎头或金主就成了空降 cto

一堆空降奇葩 cto 就是这麽来的

[ConradG]

@cest 艹，我又中计了。

[twl007]

这个场景不现实吧 EVE 都做不到好么 巅峰也就凑够几千人同屏 但是那个时候无论渲染也好或者服务器压力也好 明显都扛不住了 CCP 为了解决这些问题还引入了时间膨胀 主动拉伸时间 最多能将游戏中的的一秒拉伸到 10 秒我记得 就上了这些技术也达不到万人同屏

[danc]

大佬适合做 ppt

[gantleman]

@cest 原来是怕我红呀，原来是怕我空降给你当 cto 。我真是要敬佩你的想象能力。云风做的三国志策略版已经冲到国产游戏第三。仅次于腾讯的哪两个。就是因为云风都公司一直在尝试新技术和新玩法。要是我有幸遇到制作人敢用新玩法，用新技术，我做梦都能笑醒。没准就能捣腾出国产第一的游戏。而且我也没听说过程序员在论坛里能决定用谁当 cto 的。也没听过程序员能在论坛里就能决定公司用什么技术是不是靠谱的。我拿出技术和想法和大家交流，我也吸取错误教训，也给大家提供一个思考的方向。也许我这辈子都做不出来我理想中的分布式系统。不过没关系，不用害怕我去给你做 cto 。至少我做 cto 不会让大家去做无聊的换皮游戏。

[pythonee]

@lychs1998 当大家在谈渲染的时候，到底说的什么意思。游戏、动画、电影都在用这个词

[zpf124]

@pythonee 换个现实的例子来说， 假设你看到一个画家在作画，还在画基础轮廓结构。
他先画了一个房子，然后在房子前面画了一棵树。那接下来他会做什么呢？ 他会把树木范围里边的、房子的铅笔轮廓线擦掉，因为这部分实际是被树挡住的，而画房子很难直接空好树的位置，所以画完了再擦最简单。

而计算机的程序去自动处理这种遮挡、形变、以及模糊并绘制成一副完整的画的过程就叫做渲染，而这一张画就是一帧，每秒 60 帧的游戏就是指程序需要一秒画出（渲染） 60 张画面。

[ohoh]

@zpf124 谢谢

[chenyu0532]

这就是我不搞这么难的游戏的原因。。搞完了绝对就秃了。。当然首先是自己菜