这是一个创建于 1551 天前的主题，其中的信息可能已经有所发展或是发生改变。
全文地址
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
 |
101
JB18CM 2020-09-14 20:52:49 +08:00
我来翻页
|
 |
102
murmur 2020-09-15 09:24:58 +08:00
@DaRenCC 剑三的外观建模太恐怖了，11 周年的烟花怎么炸帧数都不带掉的，都是简单贴图，精细但是也是贴图，外观那是最便宜 200 最贵 800 一套，各种精细建模，稍微多几个人立马卡成 ppt
|
 |
103
crackhopper 2020-09-16 14:26:50 +08:00
ARPG,FPS 游戏的需要数据强一致性+实时性。分布式，其实只是提升了并发，对一致性的效果本质上是折损的。一旦不一致发生，那动作类游戏玩起来的感觉就是：“本来已经杀死对手了，但对方抖动了一下没死”，非常影响体验。所以我从本质上不觉得基于分布式的架构可以解决实时动作类游戏，而数据一致性，这个问题往往不是什么 IO 速度量级决定，而是网络不稳定性 /数据时序不一致性，也就是大家说的游戏逻辑处理这块。如果加锁那基本 IO 速度完全只能作为参考了，锁的粒度太粗损耗大，太细一致性再次成问题。
如果题主不能优化一致性问题，那通过分布架构的方式只能提升并发，我理解也是只能支持一部分游戏。一致性要求不高的(游戏状态数据不对事件的顺序有强依赖的，弱交互的)，或者实时性弱一点的(损耗一些性能做同步)。 |
|
104
crackhopper 2020-09-16 14:33:27 +08:00
说白了，还是 CAP 的问题。P 一定是有的，C 和 A 只能选一个。一致性本身会影响可用性。假定高可用性下的性能指标，来测算对数据有一致性要求(FPS 类游戏)的性能表现，肯定是不客观的。
|
 |
105
gantleman OP @crackhopper 既然提到了 CAP，哪么必然有几种情况下的 CAP 。同进程内的 CAP，不同进程同服务器的 CAP，不同服务器同内网的 CAP，不同服务器公网的 CAP 。显然这４种情况下的 CAP 要分别讨论。例如同进程内的一致性问题，任意线程的崩溃必然导致进程重置。哪么线程崩溃导致重置导致消灭不一致。哪么问题来了，消灭不一致是不是就代表了一致呢？你看在不同背景下讨论一致性问题时会产生各种细微不同，这种不同导致的结果并不绝对相同。
|
|
106
gantleman OP @crackhopper 既然帖子都被拉黑了，我就是无忌惮的多说几句。记不清 CAP 作者还是 poxe 作者是数学博士。他们在数学尺度上讨论一致性问题我理解。数学尺度是什么意思就是超越物理的尺度。在宇宙范围都通用的理论。工程学范围的一致是什么？贴瓷砖的装修工程师要考虑一面墙的瓷砖是不是一致的，不一致业主就要往你脸上吐口水。一个贴瓷砖的师傅讨论在地球上贴砖和在火星上贴砖的通用一致性理论？怕是要扯到蛋了吧？ CAP 是不是定律，是数学定律还是工程定律？请问工程学有全部条件下都通用的定律吗？如果工程学有通用的定律，哪软件工程是不是要从土木工程学起了呢？所以我是不是要吐槽下美国软件分布式学会的哪几个大叔大婶到底再研究研究什么？
|
|
107
crackhopper 2020-09-22 13:52:17 +08:00
没看懂你说的是啥，好久没登陆了。我的意思是，你的分布式架构对一致性的保证低于单机器的一致性保证，因此有些游戏场景并不适用，至于 IO 性能就更无从谈起了。但好像你在跟我讨论的是哲学，而且是绝对主义和相对主义的辩论，我觉得离题了。你纠结的点是不存在完美的一致性，但我也没说 “强一致性等于完全一致性”；我说的是 “强一致性不等于弱一致性” 。一些 FPS 场景要求的是强一致性，你搞弱一致性或者最终一致性那套行不通。
|
|
108
crackhopper 2020-09-22 13:58:22 +08:00
实时强交互，意味着弱一致性+最终一致性体验会很差，就得强一致性。就问你个问题，1 秒钟万人互相释放魔法，释放的命中顺序对结果有影响 (比如各种 buf，或者死亡判定后命中无效)，你搞个分布式加大了 IO 吞吐，放弃了顺序的保证，施法导致的结果都不一样，你告诉我咋玩。所以我对你用分布式系统解决弱交互非实时游戏有一定可取之处，但你说强交互实时游戏，我觉得你就在扯。
|
|
109
gantleman OP @crackhopper 太好了终于我们能在一种共识上来讨论 1 万个人的问题。这里你强调 1 万人施法魔法，要保证命中顺序。我们想象一下，在 1 万人的真实战斗中。差不多相当于两个团级的军队在战斗。你作为其中的士兵你打一枪，你是否能确定命中了吗？对方倒下了是故意倒下躲避子弹还是被子弹击中倒下的？
就是战后统计死亡人数，失踪人数也都没有人能保证准确？在现实社会都不能确定的耦合性，你要求在游戏里必须准确获得一致？这可笑么？现实社会都不能确定事情？所以你看 1 万人的游戏根本不需要非常强的游戏精度。 哪么 1 万人的服务器也就不需要很强的游戏精度。也就是外在产品耦合性决定内在技术耦合性。你在扯这个扯哪个的时候，你搞清楚什么是耦合了吗？你在用准确的度量耦合吗？你准确的还原产品耦合需求和技术耦合的设计需求了吗？ 作为一个工程师基本的素养要有的。度量一个工程学上的单位时，例如耦合这个剂量单位。但强弱是个什么单位？你的所谓弱交互弱到什么程度。你要一杯热水洗脸，我给你一杯 1 百度的热水，你是不是就烫死了？不谈剂量，一会强一会弱，这是工程师该说的话吗?同样的话你要是换个地方说，能被人骂死你信不信。比如汽车工程师说我做的汽车防水性能很强。哪个防水很强是下雨不漏还是掉湖里淹不死呢？为什么我们的工程师能肆无忌惮的说这种基本工程素养都没有的话？就因为软件不死人就可以信口开河？ |
|
110
crackhopper 2020-09-22 18:51:10 +08:00
@gantleman 没你说的这么复杂。就是问你，眼前的玩家数据不一致，它到底展示是死还是活？薛定谔的玩家？还是说每个用户玩单机就行了，最终统计一下大概的数。别总举极端的例子，又不现实。我有没有工程师素养，也不是你通过简单的讨论就能确认的，我还觉得你没素养呢，用几个立方体就敢说自己的架构支持强交互，不断削弱业务对一致性的要求，真是可怕。感觉你是做网站做多了吧。
|
|
111
crackhopper 2020-09-22 18:54:04 +08:00
整个战局的折损有偏差是正常的；局部交互的时候，互相干扰，还要保证体验，不能出现“薛定谔的玩家”。你的架构对这种情况就根本没考虑，因为你根本就不关注一致性。还敢说自己支持所有的万人在线。真是，战略类和实时游戏都分不清。
|
|
112
crackhopper 2020-09-22 19:27:19 +08:00
我看你的讨论都是基于统计的，不是基于确定性的。看来你根本不懂什么是交互，交互就是我把这个人打死了，他不能下一秒再活过来。你跟我谈最终一致性，是讨论一个问题么？如果不是强交互实时游戏，确实可以用你的办法来做；而强交互你的方案根本解决不了难点，难点就是强交互的业务本身要求强一致性。
对网站来说，用户可以忍受失败，再试一次就行了；重新提交就行了；刷新就行了； 你玩 FPS，打死人又活了，你告诉我这个没关系？最终统计你打死多少人就行了？你确认你不是搞笑的？你如果打死了一个人，那么你不会防备他，他就是个尸体；如果你没打死他，那么你需要防备他，他会反过来打死你。这种事情你不保证准确怎么做？各自玩单机最终统计，那还算万人在线么？你确定你做过实时强交互游戏？ 你可能说，保证个局部一致性就行了，关键局部和局部是互连相互影响的；这块你就得有个方案，尤其是分片的边界问题；其次这种方案有了，你确定你还能万人在线？你的性能都是在不考虑一致性情况下讨论的。还好意思说别人没工程师素养，我看你是 ppt 写多了，不知道技术人该实事求是了。 吹牛逼谁不会啊。你做个万人 FPS 试试？ |
|
113
gantleman OP @crackhopper 我跟你谈如何精确度量耦合性。你和我谈用户感受？你是工程师还是产品？就像我问你，哪颗树有多高？你一直叨叨有高树有矮树。高树能做桌子，矮树只能烧。我问的高树有多高，能做几个桌子。听不懂就算了。
|
|
114
crackhopper 2020-09-23 10:54:31 +08:00
@gantleman 每日过来一喷。我以为你能提点有建设性的方案和测试手段呢，闹了半天就整文字游戏。还总举一些很蹩脚的例子，每次回复都举例子，关键例子还举得不恰当。然后乱扯一些东的西的，最后来一句，“你没量化指标，别跟我 BB”，“你没量化指标，你是产品经理，你不是工程师”。写工程写到你这种，也真是悲哀；看你就是写了点代码，看了点设计模式和分布式架构，就不知道自己是谁了。如果跟你举个数据例子，你又开始拿你脱离业务的 QPS 之类的开始辩论，你都不实现业务，讲指标有毛的意义。。。不过，恭喜你，已经形成逻辑闭环了，反正不可能有谁辩论赢得了你。大家只是探讨技术存在的问题和局限性，你跑这里秀你的逻辑闭环，真是长见识了。建议你去给一些新技术做布道，比如量子计算啥的，反正暂时也不结合什么业务应用，就靠指标吹就行了。技术圈还是需要你这种对外吹的，对内就算了，大家谁不知道咋回事啊。
|
|
115
crackhopper 2020-09-23 10:58:22 +08:00
反正你先喷我的，我也喜欢和人喷。随便你怎么骂。来吧。
|
|
116
gantleman OP @crackhopper 你说了这么多，无外乎在说一件事，用分布式不能开发 1 万人同屏战斗的游戏。因为在你的认知里这是不可能的。魔兽做出来了，每人知道怎么做的，肯定不应该是分布式，应该是有一种人类世界不存在的硬件支持。eve 也做出来，虽然不如魔兽水平高，但也肯定不是分布式的，应该是单线程的，只所以做出来是因为因特尔开发了一种主频高达 1 百 G 的 cpu 。只给魔兽和 EVE 游戏公司使用。总之不是分布式的原因，因为超出了你的认真水平。因超出了你的认知水平我就是在骂你？？？ 我没哪个闲工夫骂你，我只是告诉你们一些简单的事实。
|
|
117
crackhopper 2020-09-24 14:01:53 +08:00
@gantleman 我承认，民科自然是超出我等普通人的认知。至于你说的其他游戏怎么做出来的，以及局限性，可以自己翻别人的留言。懒得再说了。时间膨胀什么的，分场景，地图，伪万人同屏。你看看你自己强调的是啥，包括有人跟你提出了实时强交互支持不了。你来句，你们认知有问题。我就看不惯你这点。chengz 的数据就给的很客观，我看你就会瞎扯。我只是从业务上给你点一下，为啥实时强交互(真万人同屏)不可能做到，顺便给你抛出了一个业务具体的难点。你来一句，这是产品问题。我真是醉了，又开始混淆问题本身了。要注意，是你自己一直强调自己做的是真万人同屏，能支持实时强交互的，现在反过来说产品问题。那你定义的实时强交互到底是啥？你拿魔兽和 EVE 举例子，你确定他们是真万人同屏？真是可笑至极。摆脱你好好看看关于这两个游戏大家的技术分析，别跑这里来秀自己的无知。链接就不用我找给你了吧，google 都不会用那也没沟通必要了。
|
|
118
gantleman OP @crackhopper 摆在你面前的就 3 条路。
1，万人同屏技术要么单线程，但由一种我们都没见过只有游戏公司使用的 CPU 来实现。 2，万人同屏技术要么使用分布式的方法来实现。 3，否认前两条假装什么都不存在。 前两个还能称为技术问题，第三个就纯粹是哲学问题了。无论我的方法能不能实现，起码我不选择否认万人同屏技术能够实现的可能。而你呢，从哲学的角度否认任何技术进步的可能。就不说人类历史来打你脸。这么多年党的教育是白费了。你适合去印度做稳固的底层，因为你骨子里否认人类有任何进步的可能。 所以我不喜欢和你讨论哲学问题，因为你的哲学观就是我不知道的东西都是都不可能。 |
|
119
crackhopper 2020-09-24 15:37:54 +08:00
@gantleman 只是你的方案不可能罢了，你的方案属于分布式方案，并不意味着分布式方案等价于你的方案；我要批判的是你的方案，不是分布式方案，不要搞错了。另外，现在是没什么技术做到真万人同屏的，不是说不知道，不是那种玄学，而是基于现有的软硬件，实测论证的结果。参见大家举例的数据。你的方案并没有多牛逼，没解决核心问题，承认这点也没什么的。是你在那扯哲学。跟你讲一致性你说不用一致性，那有啥好说的，只能说明你不是做实时强交互游戏的；有啥好伪装的。连基本的业务问题你都解决不了，一直在回避，就问你玩家是死是活的这种状态怎么做？你都没个靠谱方案，就一个劲说是：产品问题、不需要一致性。然后是攻击我，说我没想象力。你可真太夸张了。懂不懂实事求是？没做过就承认自己没做过，不要把所有类型游戏都等同，FPS 就是和回合制的游戏有很大的差别。这是常识。
|
|
120
gantleman OP @crackhopper 我挖了个坑你就跳呀？我就知道你要这么说，但这个方案里只有分布式最基础的组件，没有任何我自己添加的东西。你连分布式最快最基础的组件都否定了，还叫不否认分布式？虽然我不想承认人和人之间在智商上的差距。但很明显认知分为两种，一种是认知本身，一种是掌握认知的技能。很明显你在分析和掌握新知识的技能上真的很差。即便我在传播知识的时候把门槛一降再降。只用最基本的 redis 来讲解。没想到还有人在这个认知的最基本问题上喋喋不休。
|
|
121
crackhopper 2020-09-24 16:20:38 +08:00
@gantleman 我哪里否定组件了？我说你的方案支持不了业务。真搞不明白你的理解力是什么鬼。
|
|
122
crackhopper 2020-09-24 16:22:17 +08:00
完全没法沟通。算了，不聊了。你自己 high 吧。看出来你也没啥技术可以说了，要不然也不会翻来覆去搞文字游戏了。文字游戏就没啥价值了，你当你自己赢了就好。
|
|
123
gantleman OP @crackhopper 不客气，祝你用我教的技术早日做出属于自己的游戏。
|
 |
124
Nicoco 2020-09-25 17:20:40 +08:00
有点东西
|
 |
125
gzlock 2020-09-26 10:11:59 +08:00 via Android
dcie 有介绍过战地的服务器机制，大概内容是 fps 游戏的服务器也有计算频率，例如一秒 30 次（低配服务器）或 1 秒 60 次计算一次玩家的交互结果。
上面讨论的 1 万人一秒内同时射击敌人，按极端情况假设都是同一计算频率内（ 0.03 秒内）互相射杀，其实可以忽略射击顺序了，有实证是在战地里我试过有射杀对方，对方也射杀我一换一同时死亡的操作。 在同一次服务器计算频率内忽略射击顺序的设定我觉得这个是合理的。 因为在现实中，两个西部牛仔快枪对决也有同时开枪同时命中的可能性。 不过在 0.03 秒内要处理一万个玩家的交互，我不怀疑，因为抛开预算谈服务器性能毫无意义，可能楼主用的是超算呢？ |
 |
126
huai 2020-09-26 10:20:15 +08:00 via iPhone
本来也想看看，不过评论这么热闹。外行还是不参与了
|
|
127
gantleman OP @gzlock 0.03 秒和 1 万要分开看。放在一起世界上任何一个 CPU 硬件都做不到。但 1 万台服务器每个服务器以 0.03 秒方式通信就可行了。分布式有分布式的技术解决方法。单机服务器有单机服务器的解决方法。
|
 |
128
nirvanacqw 2020-09-26 16:53:13 +08:00
我怎么老在首页看到这个帖子
|
|
129
gantleman OP @nirvanacqw 因为我肯掏钱推广分布式技术呀！肯真金白银拿自己钱做技术推广的才叫真爱。
|
Select Language