• 2013-10-24

    Web 开发程序员谈网游服务器开发

    Views: 11317 | 6 Comments

    今天参加了一个和某网游开发团队的交流, 感受到了网游开发和 Web 开发之间的巨大差异, 所以我写了本篇博文.

    传统的网游开发者可能由于更大的精力放在游戏逻辑上面, 并且因为游戏客户端是一个高度内聚逻辑复杂的终端程序, 所以网游开发者在开发服务器端的时候, 也容易把客户端的经验放在服务器端, 很少考虑动态可扩展性和服务容灾性.

    Web 开发的一些经验对网游服务器开发是非常有用的:

    1. 服务(子系统)无状态化,
    2. 所以服务可以采用 Web 模式来开发, 也即 Web Server + 脚本语言 + 存储

    服务(子系统)无状态化是整个系统动态可扩展性和服务容灾性的保证. 例如在 Web 系统中, 一个全静态内容的网站是无状态的, 只要部署了多个服务器, 那么用户访问任何一台服务器都 OK. 这个例子说明了服务无状态化是系统可扩展性和容灾性的保证, 同时也隐含了一个要求: 数据是同步的.

    网游程序员会立即提出疑问, 你举的例子是静态网站, 但网游服务器的子系统可不是那样的, 能实现无状态化吗? 比如, 用户连接到了某台网游服务器, 这台服务器上面会保存有这个用户的很多信息数据, 如果用户断开连接再连到另一台服务器, 那他的数据不是全丢了吗?

    其实, 如果把服务分成逻辑(指令)+存储/状态(数据), 那就可以把有状态的服务改造成无状态的服务. 因为一般的网游服务器把逻辑和存储绑在一起, 所以做不到无状态化, 所以, 也就无法动态地增加了减少服务器.

    一旦把逻辑和存储分开(如 PHP + MySQL), 就可以使用 Web 技术来开发网络游戏服务器. 逻辑本身肯定是无状态的, 所以可以任意添加和减少服务器和实例. 而存储本身经过开发, 也可以做到无状态, 如 MySQL 集群和其它的存储群集. 把一个有状态的服务改成无状态的服务, 可以通过简单地把逻辑和存储分离即可.

    Posted by ideawu at 2013-10-24 00:05:42
  • 2013-09-16

    构建C1000K的服务器(1) – 基础

    Views: 92015 | 28 Comments

    著名的 C10K 问题提出的时候, 正是 2001 年, 到如今 12 年后的 2013 年, C10K 已经不是问题了, 任何一个普通的程序员, 都能利用手边的语言和库, 轻松地写出 C10K 的服务器. 这既得益于软件的进步, 也得益于硬件性能的提高.

    现在, 该是考虑 C1000K, 也就是百万连接的问题的时候了. 像 Twitter, weibo, Facebook 这些网站, 它们的同时在线用户有上千万, 同时又希望消息能接近实时地推送给用户, 这就需要服务器能维持和上千万用户的 TCP 网络连接, 虽然可以使用成百上千台服务器来支撑这么多用户, 但如果每台服务器能支持一百万连接(C1000K), 那么只需要十台服务器.

    有很多技术声称能解决 C1000K 问题, 例如 Erlang, Java NIO 等等, 不过, 我们应该首先弄明白, 什么因素限制了 C1000K 问题的解决. 主要是这几点:

    1. 操作系统能否支持百万连接?
    2. 操作系统维持百万连接需要多少内存?
    3. 应用程序维持百万连接需要多少内存?
    4. 百万连接的吞吐量是否超过了网络限制?

    Continue reading »

    Posted by ideawu at 2013-09-16 22:01:16 Tags: ,
  • 2013-09-09

    小数据与大数据

    Views: 10509 | No Comments

    计算机编程领域有个公式:"程序 = 算法 + 数据结构", 其实, 换个角度看, 那不就是:"软件 = 逻辑 + 存储"吗? 今天就谈谈存储(数据)对于软件设计的影响.

    很多偏业务应用型软件, 在数据规模非常小的时候(例如 100M 之于 8G 的内存, 10G 之于 1T 的硬盘), 怎么做都不会是问题, 只要逻辑正确, 程序一启动, 立马就顺利地提供服务. 比如开发一个日活跃 1000 人的论坛, 随便找到虚拟主机, 用 PHP + MySQL 就出来了, 成本低廉性能稳定.

    Continue reading »

    Posted by ideawu at 2013-09-09 22:24:59
  • 2013-08-15

    在线状态服务在网站系统中的应用

    Views: 19179 | 18 Comments

    我的前一篇博客文章"谈谈Facebook的聊天系统架构", 对Facebook的聊天系统架构进行了分析. 其中的有些思想和系统划分, 对即使不是做聊天系统, 如一般的网站系统, 也是很有借鉴意义的. 例如其中的在线状态服务器(Presence).

    在线状态服务, 是这样的一个服务, 它维护了网站当前的在线用户列表, 接受其它模块的查询. 是实现统计网站同时在线人数, 维护在线用户列表等功能的基础服务. 在Facebook的聊天系统中, 在线状态是为聊天系统服务的, 所以在线状态是一种"强"在线, 也即用户保持着和Comet服务器的连接, 可随时接受服务器推送(push)的消息.

    Continue reading »

    Posted by ideawu at 2013-08-15 22:54:10
  • 2013-08-13

    谈谈Facebook的聊天系统架构

    Views: 32866 | 1 Comment

    今天看到一份 Facebook 公司 2009 年的 Slideshow, 介绍它的聊天系统架构, 其中的一张图结构非常清晰, 所以我对这张图谈谈我的看法.

    Continue reading »

    Posted by ideawu at 2013-08-13 01:13:47 Tags:
  • 2013-07-23

    SSDB存储集群

    Views: 25997 | 6 Comments

    虽然拥有主从同步结构, 甚至是多主多从的同步结构, SSDB仍然是一个单机存储数据库系统, 所以SSDB天生适合存储1TB以内的数据. 如果数据可以静态分布, SSDB当然可以存储无限的数据量. 当然, 这样的SSDB并不是一个集群, 也不是一个严格意义上的分布式存储系统, 统一入口是集群的最基本特征.

    "一致性哈希"常常被认为是分布式存储系统的一个重要概念, 事实上, 它只是一个可选的九牛一毛而已. 分布式存储要解决的重要问题不是数据如何分布, 而是如何保证数据迁移对用户不可见.

    当一个区间(r1, r2)内的数据在从S1存储点向S2存储点迁移的过程, 处于这个区间的数据的读写会涉及到定位的问题. 读问题其实很好解决, 把迁移分为复制和删除两个步骤, 那么就可以保证在复制过程中还是从S1读取. 写问题也是类似, 但要复制得多, S1必须保证复制过程中的所有写操作都被同步(sync)到S2.

    在区间内数据被删除后, S1再接收到读或者写请求时, 应该返回一个out-of-range(oor)错误, 并redirect到S2, 这时客户端可以更新寻址表然后重试.

    另外, 迁移完成后, 应该由S1进行报告, S2无权进行报告, 而只能被动地接受通知区间的变化. 也就是说, 虽然S2知道自己已经接收了区间内的数据, 但S1仍然可以在这时取消迁移.

    Posted by ideawu at 2013-07-23 00:17:18
|<<<123456789>>>| 3/11 Pages, 61 Results.