« 马上启程去北京了 | 返回首页 | 多核环境下的内存屏障指令 »

讲稿

如果不出意外的话，我现在正在准备在 2007软件开发2.0大会 上的一个演讲：大世界网络游戏服务器的构架 。马上就要上讲台了。

其实主要是介绍下我们这两年正在开发的网络游戏引擎服务器部分的设计。这里有 PPT 可以下载 。

12 月 4 日，终于回来了。

对 PPT 中几个地方做点简单的解释，在那天似乎也讲到了这些：

  1. 数据文本化：我们甚至连 3d 模型数据都文本化了。 在实际工作中也真的带来了好处。为了弥补性能损失, 另外做了命令行工具转换。这就跟我们用编译型语言一样, 大家维护的是文本的源代码, 用的是 二进制程序。我们这些数据在 svn 上保留的是文本, 用之前要通过 makefile 和相应工具转换。性能无关的一些东西就直接用文本了。

  2. 太多单点导致故障率上升：首先, 我们的需求决定了允许单点故障发生。其次, 一个单点拆分成两个,并不意味着故障发生率上升。因为, 若把两件事一起做, 任意一件事出了问题, 同样会导致故障。这跟把任务是否拆到多个进程是无关的。如果我们强制配置多个进程在同一物理机器, 和硬件与网络也无关。反而因为单个任务变简单了, 故障率会下降, 承载力上升。如果日后某个单点需要做双份相互备份, 因为任务相对简单, 系统升级也更容易做。

  3. 采用单线程多进程：本质上在不考虑效率因素时, 多进程完全可以取代多线程模型, 且可以获得更大的健壮性。实际上多线程模型会把进程间数据传递的开销转嫁到锁开销上。这两种开销的代价比在未来是很可能发生变化的。我的整个设计是提供更长的流水线来在保证一定的反应时间的基础上加大整个系统的承载量。从设计上避免大量的进程间相互交互, 这样让数据在流水线上通常流动, 从而避免逻辑阻塞在单进程中。

  4. 二进制跨平台：我们不跨不同的 cpu 指令集。 这只需要定义自己的代码模块二进制格式即可做到。

云风 提交于 November 30, 2007 02:00 PM |

Comments

http://www.douban.com/subject/1088054/ TCP/IP 详解三卷耐心看完 :)

Posted by: Cloud [TypeKey Profile Page] | (34) December 15, 2007 12:01 AM

您 好，我想让您给我指点一下如何学习网络，我还是一个大学生，我不知道从哪下手，谢谢您云风老师

Posted by: 简单 | (33) December 14, 2007 05:19 PM

云风估计得是中国游戏界最牛的了

Posted by: Anonymous | (32) December 13, 2007 10:10 PM

deep cold == 深寒 ?

Posted by: ll | (31) December 10, 2007 10:34 PM

我做过银联的核心转接系统.看了你的PPT,对其中的一些内容很感兴趣 可是在CSDN的视频频道却没看到你演讲的视频,真是可惜 http://live.csdn.net/list.aspx

Posted by: JackYang | (30) December 7, 2007 08:25 PM

没啥新鲜的dd...

Posted by: ... | (29) December 6, 2007 02:53 AM

内容很精彩，很喜欢

Posted by: ogmw | (28) December 5, 2007 03:40 PM

另外，锁竞争在锁碰撞频率很低的时候是没有什么消耗的 刚才设计了一个测试例 线程循环执行体 进入临界 锁内操作 固定消耗时间90ns,大概相当于操作100字节数据 离开临界 锁外操作 设为t，变化这里决定了锁的竞争频率 线程连续工作,统计固定时间内的循环执行次数 这样，变化测试线程组的大小及锁使用时间，统计全组最终总体执行循环次数就可以了解lock对 效率的影响。 结果如下 注:测试机器为双核 E4300 @ 2.7G , win2003 线程数 2 (无lock) 2 10 t取值 1 us(百万次/秒） 15760 k 4593k 11770k 10us(10万次/秒) 1757 k 1728k 1753k 100us(万次/秒) 176 k 175k 176k 可以看到，排除时间误差后，在10万次/秒及更低的频率级别上，锁没有带来实质性的性能损失， 而在100万次/秒的频率中，是不适合用锁的，8过这个貌似都是内核级的东西了，游戏应用中是不存在这么大的处理频率的，以网络数据包处理为例，一般也就是每秒10k处理量左右吧。

Posted by: Anonymous | (27) December 5, 2007 11:45 AM

跨进程数据交换还是比同进程跨线程的数据交换要慢的多啊.这样为了达到效率只能用数据累积成批发送吧,这样是不是提高了处理延迟,降低了用户的手感呢?

Posted by: Anonymous | (26) December 5, 2007 10:26 AM

感谢大家，学习中

Posted by: alioxp | (25) December 5, 2007 09:46 AM

对RPC的使用我有些质疑。 虽然在UNIX下它很方便。 但效率总不太高。 当初用C取代C++的得来的效率不就浪费了吗。 当然在UNIX用C可能是无赖之举。 要编程方便，只要花心思在接口，我想应该还是可以达到的。 还有如果用RPC是自己实现RPC吗，还是用UNIX自己的ONC RPC。客户端RPC的实现呢？实现一个性能稳定的RPC应该比实现一个性能稳定的网络底层和一个良好的接口难度要大很多。复杂很好，很大情况下，复杂即是不稳定。要不你也不会用单线程而不用多线程。

Posted by: asiantao | (24) December 4, 2007 10:17 PM

我现在做的项目正好需要这方面的知识。要是有视频就更好了。非常期待你们的游戏引擎

Posted by: 大脚 | (23) December 4, 2007 02:45 PM

其实PPT上的东西大多都在blog里面说过了，和评论一起看，可以学到很多东西。云风blog的最大优点就是：抛开对与错，引发阅读人的思考。

Posted by: bennie | (22) December 4, 2007 11:43 AM

PPT看过了，只看PPT不会看出些什么，有视频的下载才会有用。云风可以跟举办方提个建议么，大家共享。

Posted by: loverwei | (21) December 3, 2007 09:59 PM

海量数据文本化对于大大降低了系统的维护代价，特别是对于有大量外部数据的系统，不至是游戏，任何类似的系统都应该参考。

Posted by: Anonymous | (20) December 3, 2007 09:54 PM

云风说的跨平台具体细节不清楚，感觉应该就是Win32 COM所做的事情吧。 不管怎样，最期待的就是看到最终作品。

Posted by: MADLAX | (19) December 3, 2007 09:06 PM

手机剪辑板容量的问题。还有两点分开贴。 3. 采用单线程多进程的好处。本质上在不考虑效率因素时, 多进程完全可以取代多线程模型, 且可以获得更大的健壮性。实际上多线程模型会把进程间数据传递的开销转嫁到锁开销上。这两种开销的代价比在未来是很可能发生变化的。我的整个设计是提供更长的流水线来在保证一定的反应时间的基础上加大整个系统的承载量。从设计上避免大量的进程间相互交互, 这样让数据在流水线上通常流动, 从而避免逻辑阻塞在单进程中。 4. 二进制跨平台。我们不跨不同的 cpu 指令集。 这只需要定义自己的代码模块二进制格式即可做到。

Posted by: cloud | (18) December 3, 2007 07:05 PM

还在北京, 没机器上网, 所以依旧用我的 palm treo 650 回点留言。 常见的几个问题解释一下, 这些在会场其实也讲到了。如果举办方日后提供视频下载, 大家若有兴趣可以看看。 1. 数据文本化。我们甚至连 3d 模型数据都文本化了。 在实际工作中也真的带来了好处。为了弥补性能损失, 另外做了命令行工具转换。这就跟我们用编译型语言一样, 大家维护的是文本的源代码, 用的是 二进制程序。我们这些数据在 svn 上保留的是文本, 用之前要通过 makefile 和相应工具转换。性能无关的一些东西就直接用文本了。 2. 太多单点导致故障率上升。首先, 我们的需求决定了允许单点故障发生。其次, 一个单点拆分成两个,并不意味着故障发生率上升。因为, 若把两件事一起做, 任意一件事出了问题, 同样会导致故障。这跟把任务是否拆到多个进程是无关的。如果我们强制配置多个进程在同一物理机器, 和硬件与网络也无关。反而因为单个任务变简单了, 故障率会下降, 承载力上升。如果日后某个单点需要做双份相互备份, 因为任务相对简单, 系统升级也更容易做。

Posted by: cloud | (17) December 3, 2007 07:02 PM

才注意到，这个留言程序，没有认证码机制，很容易被机器人灌水

Posted by: 我是谁 | (16) December 3, 2007 02:54 PM

二进制跨平台，只能是同体系不同OS之间吧。举个例子，在FreeBSD上可以通过加载linux-emu，运行linux程序。而且FreeBSD还可以加载一些Windows的驱动呢。这些都是相同的指令集系统，区别是文件组织格式不同。 另，这份演讲，对于搞游戏的可能会有借鉴，但对于其他的生产系统，不具有太大的参考。如同现场的人，询问单点故障，这是要命的问题，但对于游戏来说是无所谓的，如果掉线，大家都掉，起码相对公平。

Posted by: 我是谁 | (15) December 3, 2007 02:52 PM

首先感谢分享.还有两个小问题:第一,对游戏逻辑中采用多进程单线程感到新鲜和不解?第二,如果能有录音或视频就更好了.在哪里能找得到呢?

Posted by: goldou | (14) December 3, 2007 12:29 PM

海量游戏数据文本化? 不可思议。

Posted by: smart324 | (13) December 3, 2007 11:40 AM

讲稿引用细节太多，还要找些时间才能细看，能有现场录音就好了，呵呵，毕竟ppt只是一个概要、框架而已 PS.虽然白底黑字看起来清爽简单，但实际演讲的时候观众有没有反映看不见呢？

Posted by: 天堂的隔壁 | (12) December 3, 2007 09:51 AM

奇怪，30日下午2：00时似乎没有发布，我记的来看了的。二进制跨平台，这个比较神奇啊。

Posted by: alioxp | (11) December 3, 2007 09:32 AM

什么是"大一统的设计"， 数据批处理？

Posted by: k120 | (10) December 2, 2007 01:14 PM

数据文本化有利于维护，但是会损失一些性能。 对于小量的数据可以这样做，但是对于大量的数据，还是应该定义专门的数据结构，以及实现相关的工具。

Posted by: rockcarry | (9) December 2, 2007 10:07 AM

恭喜前辈实验成功，好PPT先收下了。。：）

Posted by: duguguiyu | (8) December 1, 2007 05:18 PM

云风 你看，韩国的游戏都把 画面做成这么美了，不能到你做的引擎做出的画面能出什么效果呢。看这儿视频：http://news.17173.com/content/2007-11-30/20071130100138027,1.shtml

Posted by: 宾格 | (7) December 1, 2007 05:14 PM

此来八卦一把。 大世界-Big World? 这是刚看标题时的误会。 还有： cloud刮得久了（实际已经很多年），就有点冷了，就变成了deep cold? deep cold之“风魂”升级版？ 很喜欢你的ppt,没有背景图片，几乎只有白色和黑色，结构简单明了，字字值千金，并聪明地逃过版权问题。 谢谢，也许你技术不是中国游戏界最强的，但是如果要评上过去几年到未来几年对中国游戏发展有重要意义的十大人物的话，你一定列在其中。

Posted by: asiantao | (6) December 1, 2007 02:11 PM

曾经追求大一统的设计 过分信赖 C++ 设计模式滥用 数据应当文本化 应将每单个任务足够简化 不为尚不存在的需求做设计 除了“数据应当文本化”之外，我都同意。 这些东西你的日志上已经说了很多，我也已经学习了很久。不过最后看到这几条，心里还是很欣慰。

Posted by: Atry | (5) December 1, 2007 01:57 PM

云风老大是好人啊

Posted by: 夜夜叶想 | (4) December 1, 2007 01:40 PM

内容有些粗，要是再细致点就好了

Posted by: seek | (3) December 1, 2007 01:09 PM

老大，我好喜欢你的 DEEPCOLD的标识。好COOL

Posted by: hchc | (2) December 1, 2007 09:29 AM

cool good luck

Posted by: rockcarry | (1) December 1, 2007 09:21 AM

Post a comment

非这个主题相关的留言请到：留言本