这是一个创建于 1923 天前的主题，其中的信息可能已经有所发展或是发生改变。
全文地址
https://zhuanlan.zhihu.com/p/195059458
在<使用 redis 实现 5 万人同服的'相位技术'>中我介绍了基于九宫格和相位技术的空间管理技术。这里我们也要借鉴游戏服务器中“服务”的概念。可能有些同学没有接触过游戏服务器，对服务的概念不是很熟悉。服务可以看做是一个独立的线程环境。这个线程监听着一个消息队列。其它的服务可以发送消息给他。这种方式在服务器开发中的 go 语言，erlang 语言，skynet 框架中被广泛应用。消息队列保证了服务所创建的数据是私有并且多线程安全的，只能通过消息通讯的方式进行修改。服务的概念为多线程下使用数据的安全问题提供了保护。通过消息通讯建立了在多线程下的秩序。但这种方式在客户端使用的并不多。各种服务的框架也都是在服务器端使用的多。
客户端使用多线程开发管理 1 万多个线程将会是一场噩梦。而管理 1 万多个服务对技术水平要求也还是比较高的。针对客户端没有多线程的服务框架问题，我开发了 pelagia 框架。借用“服务”的概念来管理客户端多线程。通过内嵌 kv 数据库和预判以及服务私有数据的概念彻底消灭多线程死锁和依赖的问题。因为只有解决多线程的安全问题。才能进一步思考如何优化通信和计算以及存储的平衡问题。安全问题不解决所有的优化问题就会是空中楼阁。
全文地址
https://zhuanlan.zhihu.com/p/195059458
https://zhuanlan.zhihu.com/p/195059458
在<使用 redis 实现 5 万人同服的'相位技术'>中我介绍了基于九宫格和相位技术的空间管理技术。这里我们也要借鉴游戏服务器中“服务”的概念。可能有些同学没有接触过游戏服务器，对服务的概念不是很熟悉。服务可以看做是一个独立的线程环境。这个线程监听着一个消息队列。其它的服务可以发送消息给他。这种方式在服务器开发中的 go 语言，erlang 语言，skynet 框架中被广泛应用。消息队列保证了服务所创建的数据是私有并且多线程安全的，只能通过消息通讯的方式进行修改。服务的概念为多线程下使用数据的安全问题提供了保护。通过消息通讯建立了在多线程下的秩序。但这种方式在客户端使用的并不多。各种服务的框架也都是在服务器端使用的多。
客户端使用多线程开发管理 1 万多个线程将会是一场噩梦。而管理 1 万多个服务对技术水平要求也还是比较高的。针对客户端没有多线程的服务框架问题，我开发了 pelagia 框架。借用“服务”的概念来管理客户端多线程。通过内嵌 kv 数据库和预判以及服务私有数据的概念彻底消灭多线程死锁和依赖的问题。因为只有解决多线程的安全问题。才能进一步思考如何优化通信和计算以及存储的平衡问题。安全问题不解决所有的优化问题就会是空中楼阁。
全文地址
https://zhuanlan.zhihu.com/p/195059458
 | 1 clf 2020-08-23 10:24:52 +08:00  2 但万人同屏的难点难道不是在人物 /角色模型高速&高质量渲染上么…… |
 | 2 gantleman OP |
 | 3 across 2020-08-23 10:34:14 +08:00 @lychs1998 我自己没做过。但是记得超大数量的，都是同类型的重复渲染，unity 以前也出过类似教程，比如 GPUInstance 相关的： https://blog.csdn.net/leonwei/article/details/73274808 |
 | 4 murmur 2020-08-23 10:39:59 +08:00 1 我也不知道万人同屏的场景是啥，现在 mmorpg 一般一个服务器跑到死也才八千一万人，玩的时候同屏 200 人以上优化差一点的游戏就 gg 了，当年魔兽世界冬拥湖都没扛住渲染压力 |
 | 5 pabupa 2020-08-23 11:20:19 +08:00 via Android Earth online? |
 | 6 learningman 2020-08-23 13:11:32 +08:00 @pabupa Earth Online 万人同屏也不多见。。。 |
 | 7 dogfeet 2020-08-23 13:41:24 +08:00 游戏中的这种场景，一般都是不用 redis 的。如果考虑支持在线数高，还是偏向于数据直接放在场景服务的内存中。 |
| 8 gantleman OP @dogfeet 现在用 redis 很多了，毕竟谁也不敢说自己写的缓存服务器比 redis 强。场景服务器是第二代服务器的概念，魔兽十年前就已经是相位技术的第三代了。 |
 | 9 chihiro2014 2020-08-23 20:57:45 +08:00 @lychs1998 渲染这种其实放本地，倒也不算啥。难点其实在于其他人的实时状态和网络带宽利用上面 |
| 10 murmur 2020-08-23 23:23:50 +08:00 @gantleman 恰恰相反，魔兽是通过相位技术打散玩家，减少负载的，以前练级就测试过，同一个服务器，同一个工会的人，在一个图升级，一些人是看不到另一些人的，都被送到其他位面了 |
 | 11 sola97 2020-08-23 23:35:07 +08:00 GPU 吃不消 |
| 12 gantleman OP @murmur 我在另一篇文章介绍了服务器如何使用 redis 实现位面技术。https://zhuanlan.zhihu.com/p/166347236 。这里介绍的是并行技术如何应用到客户端实现万人同屏。例如使用万人同屏实现单机游戏如骑马砍杀或刺客信条。 |
| 13 gantleman OP @sola97 万人同屏由 3 个问题组成，我在详解(1)做了解释 https://zhuanlan.zhihu.com/p/195065464 。渲染能力是这 3 个方面限制的一种。网络游戏的服务器和单机游戏的 AI 处理也都限制了万人同屏技术。 |
 | 14 onionKnight888 2020-08-24 08:50:13 +08:00 @murmur 大灾变之后吧 |
 | 15 oneoy 2020-08-24 09:00:20 +08:00 via Android 单机 5w 人？ 我写的后端目前单机 8k 人在线没问题 服务器配置 4h8g |
| 16 gantleman OP @oneoy mmorpg 能做到 8k 人已经棒棒的了。魔兽没使用相位技术前只能做到 2 千到 3 千人。国内普通水平在 5 百到 1 千人。 |
 | 17 luckyrayyy 2020-08-24 23:02:18 +08:00 via iPhone 永恒之塔有 4 ～ 6k 人同地图军团战的场景，但是也不会出现在一个屏幕吧……而且客户端早就爆了，把所有人的模型给去掉，施法特效去掉才勉强能玩。 |
 | 18 yanguangs 2020-08-24 23:05:34 +08:00 1 @onionKnight888 WLK 引入的,联机的时候就能很明显的看出来,做完主线的人跟没做完的人相互看不到. |
| 19 gantleman OP @luckyrayyy 同步一万个玩家的数据需要多方面的硬件支撑，目前百兆光纤的速度是 10M 每秒。10M 除以 1 万就是 10 来个字节了。同步一万个玩家的数据对带宽，显卡，服务器都是战。 |
 | 20 993651481 2020-08-25 00:19:34 +08:00 万人同屏 = 暂时办不到 |
 | 21 Mac 2020-08-25 01:16:35 +08:00 via Android 百人同屏就能卡成 PPT |
| 22 sola97 2020-08-25 02:47:06 +08:00 via Android 我玩的 VR 社交游戏，头显单眼 1660x1440，玩家每人平均 3 万面，30 人同屏就掉到十几帧了，啥时候能做到刀剑神域那样？ |
 | 24 weizhen199 2020-08-25 08:50:13 +08:00 只渲染血条都能卡死.jpg |
| 25 gantleman OP @weizhen199 @sola97 @993651481 @Mac 有次听制作人说他调研玩家，对 5 千人以上的团战非常感兴趣。我还不太相信，万人同屏的概念都出来这么久了，大家对这个热情还这么高。 |
 | 26 undef404 2020-08-25 13:17:08 +08:00 不懂就问, 万人同屏感觉主要压力在客户端这边. 服务器这边万人在线和万人同屏有啥区别么? |
 | 27 yangbonis 2020-08-25 14:11:17 +08:00 via iPhone 站在一万人的广场上也不会每一个人的动作都在意啊 |
| 28 gantleman OP @yangbonis 你这个问题非常好啊。站在 1 万人的广场上有两个含义，你可以和其他 1 万人做交互，你也可以选择不和其他人做交互。你有选择互动的权利。在屏幕上画 1 万个假人，这些不能互动的假人，你就没有权利去交互了。对于游戏策划的意义就更多了，没有交互的权利那么这个假人就是个贴图，对策划来说意义非常有限。可以交互，可以选择性的交互，这样的互动就可以设计出无穷的玩法。 |
| 29 gantleman OP @undef404 就网络游戏来说，万人同屏的压力从客户端渲染开始，网络，服务器硬件，集群硬件，ai 软件。这整个链条任何一点出现瓶颈，最终反映到玩家面前的都是客户端卡顿。所以我们会有错觉万人同屏都是客户端的锅。这个锅又黑又大，都丢给客户端哪真是太委屈了。 |
 | 30 danc 2020-08-27 10:18:04 +08:00 那么问题来了，大佬最多做到多少人同屏 |
 | 31 chengz 2020-08-27 10:30:35 +08:00 对于 MMO 来说，万人同屏其实是一个伪概念。 真万人同屏（玩家视野上限一万人，客户端实时刷新视野）---- 无法实现 万人同服（玩家视野上限 200-400 人，同地图内玩家可以强交互，多个场景负载，相同场景可平行扩展 万人同地图（玩家视野上限 200-400 人，单场景最高一万人，同场景玩家强交互） @gantleman 题主说的是哪一种？ |
| 32 gantleman OP @danc 当然是韩信点兵多多宜善，理论上同屏人数没有上限。我还不是大佬，推广新的并行计算工程学方法也刚刚开始。过去 70 年里硬件都是以 cpu 主频率为主导。真正并行计算的硬件爆发增长也只是最近几年的事情。amd 把牙膏厂 1 万多的硬件硬拉到了 5 千多。才让 8 核心的 cpu 普及开来。软件也经历的从汇编语言的扣性能，到 java 部分性能自由开始注重快速开发稳定运行。以后也肯定能做到并行计算的自由。现在硬件的极限是 128 。我预测未来 10 年会有 500 核到 cpu 普及。那时候才是并行计算真正的爆发期。 |
| 33 gantleman OP @chengz 你说的的问题是目前的业界使用的技术上限太低的问题。先不要急着下结论说这是伪概念，无法实现的等等。讨论上限的问题就是讨论如何突破上限的问题。既然都是做技术的，那么就要用技术语言来说明问题。你既然认为万人同屏有问题。那么在客户端到服务器这长长的链条中是哪个技术环境限制了玩家视野的上限？ |
 | 35 charten 2020-08-27 11:40:46 +08:00 1 @sola97 我觉得是 cpu 吃不消，因为通过可视区或者九宫格技术裁剪掉“看不到”的场景，减少绘制面数。而 cpu 的化，如果不是追求实时，其实可视区外的对象可以降频计算，不过无论如何，gpu 可以少算，cpu 不行... |
 | 36 takemeaway 2020-08-27 15:15:41 +08:00 @chengz 他说的万人同屏实际上是万人聊天室，玩家交互很少，只不过是同服务器交互。 怎么可能一个屏幕装一万人 |
| 37 chengz 2020-08-27 15:50:08 +08:00 @takemeaway 仔细看看题主的历史发言，这个问题已经不重要拉。 |
 | 38 lichdkimba 2020-08-27 19:34:34 +08:00 |
| 39 gantleman OP @lichdkimba 祝愿中国的游戏资本和策划人早日作出世界水平的 3A 大做。 |
 | 40 xuanbg 2020-08-28 10:01:08 +08:00 万人同屏，肯定要在渲染上面偷梁换柱。。。 |
 | 41 crclz 2020-08-30 08:08:58 +08:00 服务端渲染，传视频过来 |
 | 42 fireapp 2020-08-30 08:58:04 +08:00 via iPhone 刚会写 crud 的人都喜欢扯 n10k，100k，1wk，但没有几个知道 n 是啥东西。罗列堆积名词 楼主的万人同屏连群聊都算不上 |
| 43 gantleman OP 1 @crclz @fireapp 即使有视频谁能保证不是作假呢？ 单机的示例在这里，都是开源免费的哦。 https://github.com/surparallel/unity_example_of_pelagia/tree/master/3D_Ten_Thousand 第一，我希望中国在游戏领域能做出自己就大做，中国游戏人都努力几十年了，还在捡国外的剩饭太苦了。 第二，我的技术都是开源免费的，这样的探索无论对错都是在给后人铺路，错了可以节约大家的时间，您笑一笑可以少走弯路。 第三，您用我的技术赚钱了也不用给我一毛钱。您夸我也好，骂我也好我都不介意。要是骂我能把我骂出名了，我还要谢谢你呢。 |
| 44 danc 2020-08-30 22:00:09 +08:00 大佬别光纸上谈兵啊，来个实际的游戏让我们体验体验 |
 | 47 colincat 2020-08-31 19:30:24 +08:00 万人同屏的话客户端需要做一些特效的过滤，没那么简单，哈哈，这个早都有人搞过了 https://blog.csdn.net/jiangguilong2000/article/details/59514646 |
| 48/div> dogfeet 2020-08-31 20:21:22 +08:00 2 在知乎上又看到了这篇文章。 多说几句，超大地图，AOI 这种，跟放不放 Redis 没啥关系。所谓的相位技术也这是场景分割的一种方式。数据不放 Redis 的原因是，场景中的计算本身就需要实时，放到 Redis 中还得要异步的读写，明明用了 Actor 模型将关联逻辑分割到一起降低了并发与同步的心智包袱，又引入一个外部缓存让计算变成异步的，带来的数据一致性的问题完全抵消了 Actor 模型的优势。大量的位置数据，AI，技能延时，技能范围伤害等实时的逻辑都依赖状态，这些状态放外部存储中逻辑写起来有多麻烦尚且不说，拆的这么细，性能风险很高。连 Actor 的拆分都是要考虑粒度的，状态提出去把场景服都搞成无状态实在不觉得收益在哪里（养成等玩法无状态倒是没啥问题）。 Actor 模型在游戏界中往往用 state full 的形式，场景不是简单的状态，而是 状态+计算。 像微软的 Orleans （ https://github.com/dotnet/orleans ） 与 EA 开源的 Orbit （ https://github.com/orbit/orbit ） 这种新型的 Virtual Actor 模型的框架，游戏场景的使用都是 state full 的形式。 redis 的优势， 集群，游戏已经场景逻辑上已经通过 Actor 分割了，用不上。Actor 分割出来的逻辑数据单元关联性要强的多了。 各种数据结构，性能有没有优势不说，放外部已经高了不少延时，最主要的是复杂点的数据，没法按场景服务计算式需要的结构，直接扔 Redis，最后必然带来一个转换的开销。 各种过期淘汰策略，这在场景服务中做完全没问题啊，业务逻辑中 timer 相关的东西多了去了，Redis 反而不够用。 示例中场景，交互性太弱了，角色与角色之间的交互太少，跟真实游戏的业务场景相差太大了啊 当然，说了这么多，都只是解决大场景，同场景的一些方式方法。 万人同屏这个不敢想，个人觉得，目前的硬件，最后无论用什么方式（除了 step lock ）做到了万人同屏的效果， 我估计实时性肯定无法让玩家能感受到正常的游戏体验。 |
| 49 gantleman OP @dogfeet 你提出了问题，却又回避了问题，风险很高有多高？有哪些风险？关联要强又强在哪，有哪些好处和坏处。我们不把问题都列出来，又怎么能得出结论说哪个好哪个坏呢？用 redis 做示例是因为好懂，接口简单。并且性能在单线程数据服务中是最快的。普通程序员用演员模型加数据库写的缓存服务不可能比 redis 更快。redis 只做位置存储服务，只有两个接口写入，读取。为了文章好懂我省略了空间管理服务。并且每个游戏在空间管理上都会有细节的不同。演员模型只是一个产品上的概念，对于技术来说只能当作辅助设计工具。因为操作系统和开发本身都没有这个概念。部分语言有这个概念，然而语言到微服务又有十万八千里。如你所说纯粹的演员模型会导致通信成本激增。极端情况为每个玩家每种功能都创建服务。一方面要维护激增的接口，一方面要维护激增的硬件。 |
| 50 dogfeet 2020-09-01 23:17:43 +08:00 3 @gantleman 前面已经举例了，场景中玩家释放范围技能，技能还分各种类型，与玩家当前的 Buffer 息息相关。想想你状态都放 Redis 逻辑怎么写？ PVP 的时候，血量，Buffer，技能类型的触发逻辑还是要非常严谨的。2 人一起释放技能攻击第三方，第一个技能攻击到受击者触发一个被动 Buffer 并进入 CD，第二个技能攻击到受击者，但是被动已经 CD，不会触发。按你上面的状态都丢 Redis，先不说你那个取范围技能的所有受击方靠不靠谱，场景角色上挂的 Buffer 血量等等相关的数据不要太多，2 个技能，你要保证被动只触发一次都麻烦的很。这还只是众多技能中非常常见的一些需求。 前面说的都是场景相关的功能，场景，Scene 。什么九宫格，十字链表，相位啥的，都是应用到场景服务上的。 养成玩法就不说了，谁跟你说场景服务是每个玩家每种功能创建服务？创建 Actor 永远都是把相关的放一起，不怎么相关的分离开来的原则。 [连 Actor 的拆分都是要考虑粒度的] |
| 51 dogfeet 2020-09-01 23:33:31 +08:00 2 @gantleman 还有，你说 [普通程序员用演员模型加数据库写的缓存服务不可能比 redis 更快] 当然，特指场景服务，多少人同屏本身服务端压力就是场景服务 场景服务一般做法是，状态直接在内存中，这个内存是 Actor 的 state，Actor 可以是一个完整的小场景，亦可以是一个大场景的一个区域，根据实际情况划分。 该区域类的玩家操作直接在该 Actor 中处理，状态就在这个 Actor 内存中，而且就是原生的数据结构。各种技能的计算就像在客户端写顺序代码一样，数据会有策略落地，但是逻辑都是在内存中完成，只有加载场景才有读的动作。 并不是你想的那种 CURD，一个请求过来从数据库或者其他缓存中拿一堆丢失了结构的数据，一顿操作然后再回写数据。 |
| 52 gantleman OP @dogfeet 可能你没有写过游戏服务器，对游戏服务器的技术不太了解。redis 的异步读写每秒可以支持 10 万次，操作都是按毫秒级 ，技能释放是用户按秒级别的计算 。redis 操作再慢还能比用户的操作还慢？为什么你把完全不同量级的东西都能搅和在一起说。 |
 |
 | 54 mrdemonson 2020-09-03 12:35:24 +08:00 via Android 个人认为 redis 只能管数据持久化问题，和游戏逻辑不沾边，游戏的精髓是技能衔接和玩家与玩家的互动影响，1 万个人同屏单机刷怪，还没和 100 个人混战 pk 难度高 |
 | 56 cs8425 2020-09-03 13:11:32 +08:00 1 |
| 57 gantleman OP @cs8425 请问 10ms 就要跑完所有计算？是什么计算？数据有哪些？请问“个人写过最高 12 人的 PvP 游戏 可以肯定都是直接对内存做计算&操作”的 技术指标。内存，cpu，网络带宽占用多少？你说了很多，但我没看出来，为什么 12 人的 PVP 导致硬件不够用。 |
 | 58 shenlanAZ 2020-09-03 14:00:16 +08:00 @gantleman #52 redis 并没有那么强 曾经做过 IoT 的项目 数据会经过 redis 做校验 后来发现 redis 负载太高了 就换了验证方式不走 redis 了。 当时是初期的测试阶段 数据远达不到 10 万次 /秒。 看下来 dogfeet 讲的更靠谱。 |
| 59 cs8425 2020-09-03 14:12:10 +08:00 1 @gantleman #57 老兄 你好像没搞清楚我想表达的点? 我只想说你#52 讲的 "redis 的异步读写每秒可以支持 10 万次，操作都是按毫秒级，技能释放是用户按秒级别的计算。redis 操作再慢还能比用户的操作还慢？为什么你把完全不同量级的东西都能搅和在一起说。" 这点有个的错误: redis 毫秒级对于 PvP 游戏是不够用的 一点都没提到"12 人 PvP 游戏有硬件不够用的问题" 麻烦您再看清楚一点... 10ms 跑完哪些东西, 这个部份其实 @dogfeet #50 就有点出来了啊 不是我想杠 只是觉得您好像只看关键字... 可能我叙述不太清楚 另外再补充一下, 我弄的这个 PvP(老)游戏, 属于 TPS 射击对战 您可以想成 OW 的 TPS 版, 但是技能、攻击判定更复杂... 根据手上的资料, 户操作最慢也是 0.5 秒一次, 众数在 200~250ms 之间, 顶尖的大概是在 100ms 上下 若把攻击判定算进来, 100ms 5 次都不是不可能 跟您所谓的"秒级"差异蛮大的.... |
 | 60 scar263 2020-09-03 17:57:57 +08:00 万人同屏和万人同服并不是一个概念，请不要混淆 |
| 61 gantleman OP @cs8425 做个简单的算数题，12 个人同屏，其中每个人以每秒 60 次的频率给其他 12 个人发送广播。这个广播的数据包括移动，射击，技能。那么每秒就是 12 乘 12 乘 60 次共 8640 次服务器数据提交。假设服务端只有一台 redis 处理数据。那么理论极限每次可以每次提交处理 10 次数据请求。所以是不是我数学不好，我没想明白为什么 redis 性能不能满足你 12 人 pvp 的数据处理需求。 |
| 62 cs8425 2020-09-04 01:30:29 +08:00 @gantleman #61 先不题游戏(尤其是技能造成)的复杂度没你想的那么简单 光你这算法就能得证"毫秒级"是不够的 不知道您是否真的有去算过? 1 秒 /8640 次 ~= 0.116 毫秒 /次 (~0.116 ms/req) 也就是一次请求要在 116 微秒内完成 已经是"微秒级"了 再加上还有计算要做 "毫秒级"是肯定不够的 我还是不懂为啥你一直认为 "redis 性能" 可以直接跟 "内存操作"放在同一个等级.... |
 | 64 LennieChoi 2020-09-04 17:48:13 +08:00 现在游戏服数据都放 redis 上了吗 ，那光保证数据一致性问题就要费好大劲吧，还要加个事物吗，除了服务器变成无状态可以分布式负载计算，还有减轻内存负载，想不到数据放 redis 里有啥好处。如果说防止服务器意外崩溃，可以使其他服继续读取 redis 继续计算，那么内存缓存的服务器也有方案啊，只不过是 A 服崩了，把 A 服里的数据重新负载到 B，C，D... 等服继续计算，都是负载均衡策略。如果说玩家数据和某个服是强绑的，某个计算必须在某一个服执行，那放 redis 也解决不了这问题啊 |
| 65 gantleman OP @LennieChoi 以前也是放到缓存服务器上，不过都是各个公司自己写的。游戏数据远不比银行或互联网，可以说 99%的数据都是垃圾数据。没有那么严格的一致性要求。用户回档补些金币或礼包就可以了。过去 C++写的服务器意外崩溃很多，现在都是脚本语言，已经很少担忧服务器崩溃的事情。 |
 | 66 ConradG 2020-09-05 07:58:20 +08:00 这个题主就真的很值得……block |
 | 67 swulling 2020-09-05 08:33:11 +08:00 via iPhone |
| 68 gantleman OP @cs8425 redis 的 1 秒 /10 万应该可以覆盖 1 秒 /8640 次吧。起码差着一个数量级呢。所以肯定不会是 redis 性能不够。没错 redis 需要网络，需要解析命令，然后是使用 map 存储。起码比内存操作慢了 100 倍。如果 redis 这种基本的分布式组件都不能满足需求，哪游戏开发就不能用分布式了。mysql 都不能用了，因为性能太差。多线程有锁的开销必然也比内存操作慢。哪多线程也不能用了。文件 io 比 redis 更慢了也不能用了？你看单线程内存操作最快了，游戏服务器开发用单线程最好？ |
 | 69 k9982874 2020-09-05 10:33:11 +08:00 via iPhone 1 同意前面老哥说的，redis 不是瓶颈。 redis 可以用，但是数据直接放内存更佳。 |
 | 70 Moepo 2020-09-06 09:31:18 +08:00 via iPad 6 @ConradG 楼主提交了源码，写了源码的介绍文章。虽然认知有差，交流不是很顺畅但是也引出了一下我觉得很受用的讨论。整个楼层都在就事论事，也没有人身攻击和贴吧回复出现。我觉得这就是每天应该出现的再正常不过的帖子。 按照您的说法，看了您的回复和新帖，我觉得您更值得 10 倍被 block |
| 71 ConradG 2020-09-06 11:55:53 +08:00 4 @Moepo 原来 block 还是能被 @的 题主故意混淆“同屏”和“同服”。 题主故意规避问题的适用场景。 题主在尝试用一个高延时的点对点的消息通讯架构来做实时性要求极高的网游服务端逻辑计算，避而不谈网游中重要的群体状态管理如何在这样一个弱一致架构下实现，同时对时间开销也含糊其辞。 我同意 LS 的一些意见，这个架构可以拿来写部分页游。但是 LZ 这系列文章的开头又偏偏举了 Aion 和 Eve 两个典型 MMORPG 端游的例子。 题主对于网游中重要的数据一致性的认知非常神奇。如果数据出问题都是回档发礼包，第二天可能是运营提刀上门，第三天估计就是资方提刀上门了。 再结合题主的过往文章。我觉得到此为止，大多数人足够判断题主是单纯的认知有问题，还是揣着明白装糊涂而有其他目的了。 |
 | 72 cest 2020-09-06 12:06:54 +08:00 |
 | 74 twl007 2020-09-06 14:07:50 +08:00 via iPhone 这个场景不现实吧 EVE 都做不到好么 巅峰也就凑够几千人同屏 但是那个时候无论渲染也好或者服务器压力也好 明显都扛不住了 CCP 为了解决这些问题还引入了时间膨胀 主动拉伸时间 最多能将游戏中的的一秒拉伸到 10 秒我记得 就上了这些技术也达不到万人同屏 |
| 75 danc 2020-09-06 15:27:34 +08:00 大佬适合做 ppt |
| 76 gantleman OP 1 @cest 原来是怕我红呀，原来是怕我空降给你当 cto 。我真是要敬佩你的想象能力。云风做的三国志策略版已经冲到国产游戏第三。仅次于腾讯的哪两个。就是因为云风都公司一直在尝试新技术和新玩法。要是我有幸遇到制作人敢用新玩法，用新技术，我做梦都能笑醒。没准就能捣腾出国产第一的游戏。而且我也没听说过程序员在论坛里能决定用谁当 cto 的。也没听过程序员能在论坛里就能决定公司用什么技术是不是靠谱的。我拿出技术和想法和大家交流，我也吸取错误教训，也给大家提供一个思考的方向。也许我这辈子都做不出来我理想中的分布式系统。不过没关系，不用害怕我去给你做 cto 。至少我做 cto 不会让大家去做无聊的换皮游戏。 |
 | 78 zpf124 2020-09-07 14:21:37 +08:00 3 @pythonee 换个现实的例子来说， 假设你看到一个画家在作画，还在画基础轮廓结构。 他先画了一个房子，然后在房子前面画了一棵树。那接下来他会做什么呢？ 他会把树木范围里边的、房子的铅笔轮廓线擦掉，因为这部分实际是被树挡住的，而画房子很难直接空好树的位置，所以画完了再擦最简单。 而计算机的程序去自动处理这种遮挡、形变、以及模糊并绘制成一副完整的画的过程就叫做渲染，而这一张画就是一帧，每秒 60 帧的游戏就是指程序需要一秒画出（渲染） 60 张画面。 |
 | 80 chenyu0532 2020-09-09 09:55:47 +08:00 这就是我不搞这么难的游戏的原因。。搞完了绝对就秃了。。当然首先是自己菜 |
 | 81 devwolf 2020-09-09 15:37:45 +08:00 1 @ConradG 个人观点，#71 更全面的 block 原因讲解远比#66 的"这个题主就真的很值得……block"更有意义。 即使 #71 交代了原因，若没有#70 楼无意中代表我发表了意见，我将无法从#71 得到新的观点。 我是个忙前端开发的应届生，完全不懂游戏这块，依旧保持着小白憧憬，很津津乐道的在看楼上大佬们之间的辩论，虽然不可能完全理解但想要尽量的留下印象。 我无法辨别你们两方观点的是非曲直，上面的记录使我觉得帖主应该会乐意参与的异议讨论（结果而言大概是没有回答#71 ）。 我觉得#71 远比#66 要妥当，若真如你所言帖主存在#71 的问题，看到这么吝啬赐教的大佬我只能怪罪于运气不好。 “尽量让自己的回复有意义”这是我对 v 站留下的印象（虽然我自己也很难做到），我依旧觉得#71 不是#66 的理由。 |
| 82 devwolf 2020-09-09 15:56:17 +08:00 @ConradG 首先，假设你说的“题主单纯的认知有问题”成立，那么“揣着明白装糊涂”明显是不合常理的，自然是“有其他目的”。 有哪些其他目的呢，不就是把话题的展开的更有意义。 “无预设的提问”并不受“预设”影响、“预设有偏差的提问能否有不受错误预设干预的完美回答”， 退一步问，上面所有展开辩论的预设都是完全错误的吗？ |
 | 83 psyche 2020-09-10 10:53:49 +08:00 2 @devwolf #82 楼主提供的不是有意义的回答。 你没有发现吗，没有质疑楼主的回帖基本都是没有实际游戏服务端编程经验的人。 你可以看一下楼主前几天发的帖子，他在 Github 上所谓的开源项目一千多个 star 都是花钱刷的，这个他自己也承认，他声称这样是为了推广有用的技术，Github issue 里面都是他自问自答，对于楼主的项目和文章的质疑，他从来没有正面回答，只是胡搅蛮缠或者强调自己有十几年的经验也“写出了实际的开源代码”，“比你们空质疑强”。 根据楼主的发言，有经验的开发者觉得：“楼主的东西没有人用”，“楼主没有实际的高实时性游戏服务端编程经验”，这些是很自然的推理。这些是经验判断，经验不一定总是对的，但通常很有用。 楼主的东西做一些实时性不高的页游服务器或许没有问题，因为实时性不高的页游用什么做都问题不大。 质疑楼主的人跟楼主都没有仇，但是大家工作生活都很忙，没空陪楼主浪费时间。 前几年出现了大量做手游的初创公司，确实有一些公司做技术选型的服务端主程是新手，这几年由于版号限制这种情况几乎没有了，现在有能力做技术选型的人基本不需要楼主的东西，你大可放心，楼主忽悠不到人的。 以上都是经验判断，不一定是对的，你不信的话可以拿楼主的项目做个 moba，arpg 或者 fps 的 demo，测一下数据，然后回来打我们的脸。 最后提醒一下各位新人，要快速进步的话，最重要的技能是学会不要在什么地方浪费时间。 |
| 84 gantleman OP 1 @psyche <使用 redis 实现 5 万人同服的'相位技术'>这篇文章在知乎有 4 百多个赞，我不想质疑这些点赞的人都是没有实际服务器编程经验的人。为什么要回复你是因为你在教育年轻人什么是靠普。我没有说过我做的技术都是靠普的。靠普的技术我想也轮不到我去教。在关于 redis 的文章里 redis 主从集群是非常普通的技术了。独立位置服务也是被公司常常使用的技术。让我惊讶的是都 2020 年还拒绝使用 redis 。还在强调单线程是性能最好的服务器。还有拒绝使用分布式的服务器开发。难道你们的服务器都是基于汇编语言开发的单线程服务器？我刚入行的时候也有些老师傅教育我，汇编语言是世界上最快的语言。C 语言都是异端，java 语言只能开发网页。而如今我会使用 C 和 java 但再也没有使用过汇编。最靠普的东西不需要老师傅去教育。如今教育我的老师傅也不知道在哪了。linus 发明 linux 的时候只是一个在校的研究生，按背景口水人的话 linux 操作系统就不存在了。世界潮流浩浩荡荡，唯一靠普的就是保持开放的心态不断尝试新东西。最重要的技能就是学会浪费时间。 |
 | 85 leimao 2020-09-10 13:14:10 +08:00 知乎吧，懂得人还是少，大多都是不懂跟风的。我基本很少在知乎上看技术的东西，娱乐的东西倒是可以看。别对知乎太较真，也别把知乎当成知识和学术的殿堂。 |
| 86 psyche 2020-09-10 13:17:14 +08:00 @gantleman #84 认真回你，并发框架是很核心的关键代码，你想推广的话把你的核心代码精简一下，写个介绍吧，最好配上用数学语言对算法正确性的证明过程（说明为什么用你的算法能避免死锁，以及其他问题），讲并发的技术书都有这种内容，你写出来以后有高中数学基础的基本都能懂，有多少点赞根本无关紧要。 |
| 87 gantleman OP |
| 88 psyche 2020-09-10 13:29:09 +08:00 3 大家都听说过“民间科学家”吧，民科声称自己解决了悬而未决几百年的科学难题，专家说你这是错的，民科表示自己热爱科学，几十年努力还要反抗学阀的压迫多么艰辛，学阀尸位素餐只会骗科研经费，看不懂我的高深解法于是说我是错的。民科声泪俱下感动了一些观众，于是有人说，不管民科是不是对的，至少讨论是有意义的，你看他多可怜，还有人点赞呢！ |
 | 89 icestraw 2020-09-10 14:00:13 +08:00 @ConradG 我觉得你说的对，楼主根本没有想讨论技术问题，连软广都算不上。我能理解评论里心怀善意的人多，但是，姑且不论楼主讨论 /文章 /态度的问题，你们稍微翻一下这个人的实际作品（而非文章），就知道这就是个江湖骗子，只是手段稍微高明点。 我把他文章里的项目地址 po 出来给大家评判吧，截止 2020-09-10 知乎链接里的项目地址： https://github.com/surparallel/pelagia |
 | 90 yueyoum 2020-09-10 14:49:49 +08:00 2 本来在知乎 看到这篇文章， 当时想评论，但是 知乎没登陆， 懒得评论了 在 v2 又看到， 先说结论吧： 从 LZ 的言论来看，LZ 没做过高强度交互的 游戏服务器， 做的应该都是 CURD 。 我 N 年前 刚入行的时候 也搞了一个 万人同屏的 AOI 算法， 1w 个单位，都在随机移动，这些单位每帧把 以自己为中心，半径 10~30 米范围内的 其他单位选出来，（用来支持视野，或者 AOE 技能） 记得当时 这些单位先随机移动一次， 然后再获取自己的 AOI， 大概消耗 20ms 的样子 （ c++代码） LZ 用 redis 试试 要多久。 高强度交互的游戏服务器， 状态和计算是无法分离的， CS SOURCE 比赛服务器 是 100HZ， 每帧计算不能超过 10ms COD 网游服务器 20HZ， 几百人在一个场景里，还有各种载具，物理计算，弹道计算，服务器 50ms 能做完这么大规模的计算已经很厉害了 你玩玩 LOL 吧， 那么复杂的技能判定， 你放到一个通过网络的外部缓存， 试试， 卡的玩家怎么玩？ 你说 redis 这么快， 怎么可能卡？ 就算 redis 真的能 1 秒 10w 操作，1ms 100 次操作 那么 100 人的 团战， 每个人都在移动 （写 redis ） |
| 91 gantleman OP @yueyoum 谢谢你提供的失败经验。100 人团站，每个人每秒 60 帧提交移动数据，是每秒提供 6 千个数据。每秒 6 千次的写入压力 redis 还是可以承担的。 |
 | 92 pushback 2020-09-10 15:48:46 +08:00 我不是做游戏的，我以前玩过剑网三，3d 游戏里好像有个视距的概念，剑网三那边拉大最多也是几百同屏渲染，因为太远了好像玩家这边细节上看不清楚。 顺便问下大佬如何应用服务器转游戏服务器有什么学习路线 |
| 93 yueyoum 2020-09-10 15:49:26 +08:00 2 上面没 打完 就发出去了， 继续： 每个人都在 移动 ， （写 redis ） 获取周围视野 （读 redis ） 释放技能 需要判断自己条件是否满足，甚至某些技能只有特定场景才能释放 （读 redis ） 这是一个飞行技能， 技能也搞成一个 actor 了， 它自己又要 (读写 redis ) 技能打中玩家了， 要通知这个玩家 状态变更 （写 redis ） 玩家 扣血后， 给自己喝药， 这个药每秒加 10 HP (有是写 redis) 上面这些变化，周围其他玩家都要知道， 得通知周围玩家 获取视野，下发客户端 （读写 redis ） 这只是一个简单的例子， 一个玩家移动，释放技能，使用道具，视野同步 就要消耗 大概 10 次 redis io 但是考虑写放大，周围的玩家都在频繁交互，你一个 AOE 打了周围一圈， 周围一圈的玩家因为反弹伤害又给你打回来也 如果你周围有 10 个人， 就会放大到 100 次操作。 如果周围玩家 反弹的是 AOE 伤害， 那么 这个量级轻轻松松突破 1000 。 那我们就考虑这种情况， 就算玩家 在激烈战斗的时候 1 秒才操作一次， （事实上激烈战斗的时候 一秒操作 5 次轻轻松松） 100 个玩家 1 秒 会对 redis 产生 100 *1000 的 io， 刚好 1ms 100 的 io 仅仅是 100 人， 就把 redis 压垮了。 所以，高强度交互的游戏服务器， 数据只能在进程的内存内处理， 别说 redis 多块， 网络开销都能把人卡死。 一个 20HZ 的服务器， 每帧处理时间就算 40ms， 估计你网络传输就要花掉 10ms， 再加上 编码解码这些额外的工作， 也就是 一半的性能 被你 用 外部缓存给浪费了。 当然 LZ 如果做的是 CURD 项目， 那随意 |
| 94 yueyoum 2020-09-10 15:52:10 +08:00 1 @gantleman >> 100 人团站，每个人每秒 60 帧提交移动数据，是每秒提供 6 千个数据。每秒 6 千次的写入压力 redis 还是可以承担的。 看来你从来 不考虑 交互啊， 所以扯出了 这么一个方案。 照 LZ 这么想， 无缝大地图 这个业界难题， 在 LZ 这里 轻松解决 可以去 网易 /腾讯 年薪 100W + 了 |
 | 95 livepps 2020-09-10 20:42:52 +08:00 1 @yueyoum 赞同，强交互的网路游戏，服务端数据只能做在内存，扛不住的时候，才考虑把一部分耦合低的业务拆解出来放到其他服务器上跑。其实现在很少做什么几千，几万人同屏了，首先玩家体验不好，还有技术上没有好办法解决，最简单就是降低服务器的帧率。 现在更多的游戏类型，都是开房间的，轻松做成分布式，每个服务器开 n 个房间，房间服务器之间不交互。看知乎上说 dota2 的服务器，一台也就承载 100 局比赛，也就是 1000 人，国服在线好像是 50w 的样子，也就是需要 500 台服务器。 |
| 96 livepps 2020-09-10 20:44:42 +08:00 redis 是好东西，但不是用来解决这个技术难点上的。 |
 | 97 OneMan 2020-09-10 20:57:44 +08:00 实时性这么高的东西，这些数据不放内存而放 Redis，疯了吧！ 方向错了，越努力越偏远。 |
| 98 OneMan 2020-09-10 21:11:46 +08:00 @psyche 我也感觉 LZ 是“民间科学家”，扯名词厉害。互动性要求这么高的东西，还用 redis 还毫秒级，醉了。跟他扯多了都是没意义的。 |
 | 99 DaRenCC 2020-09-13 08:57:44 +08:00 强烈要求 LZ 去西山居，帮他们改善剑网三的攻防系统，打攻防只能看名字，太离谱了 |
 | 100 lele2019 2020-09-14 09:49:07 +08:00 技术圈的眼球看来还是很好赚的。。。看来掌握到了 UC 震惊部的精髓。。。 |
Select Language