rangercyh

学东西难道不是自己学吗？在公司学什么？

前两天刚配了电脑，送你我的配置：

九州风神（ DEEPCOOL ） 玄冰 400 CPU 散热器
技嘉（ GIGABYTE ） B85M-D3H 主板 (Intel B85/LGA 1150)
西部数据(WD)蓝盘 1TB SATA6Gb/s 7200 转 64M 台式机硬盘(WD10EZEX)
技嘉（ GIGABYTE ） GV-N960WF2OC-4GD GTX960 1216-1279Mhz/7010Mhz
金士顿(Kingston)DDR3 1600 8GB 台式机内存 × 2
乔思伯（ JONSBO ） QT01 塔式静音机箱 铝饰板 黑色 汽车隔音材料
全汉（ FSP ）额定 450W 黑骑士 RA450
戴尔（ DELL ）专业级 P2414H 23.8 英寸升降旋转支架 IPS 液晶显示器
Intel/英特尔 至强 E3-1231 V3 散片正式版 CPU 代 1230 V3
IKBC C87 德国 cherry 樱桃轴机械键盘可改光
雷蛇（ Razer ） Deathadder 炼狱蝰蛇 1800 DPI 游戏鼠标
择木宜居组合书桌 台式电脑桌子办公桌 写字台电脑台 深胡桃色 小号 92*61*87cm
金士顿（ Kingston ） DT SE9H 16GB 金属 U 盘 银色亮薄

从桌子到 U 盘一条龙服务，还差音响跟麦克，这两样我都有现成的，所以没买，如果不超频可以参考下，哈哈：）

@f0rger nodejs 表示很淡定

bingo 了！邮件已发，望回复，祝大卖 @huangz

占坑

哈哈，昨天我也遇到这个问题，笑死我了。。。 0-11

一个月不看 nodejs 的版本号，再看一眼，我都吓尿了。。。

谢谢楼主，介绍一下我正在开发的游戏吧。

我以前是做端游的，那个时候后台数据冷热是分离的，冷数据落地到 mysql 或者 oracle 之类的关系型数据库里，当服务器启动的时候从数据库里把冷数据做一定筛选加载进内存里，然后当玩家登录时玩家数据也被从数据库加载进内存。玩家数据的存储有两种方式，一种是按照一定时间间隔进行热数据落地，一种是一旦发生变化就落地。那个光辉岁月里，服务器启动的时候要加载很多公共数据，所以对于一个日活上万的服，注册比按 1 ： 100 来算，如果数据处理写的不好，很可能服务器启动的时候要加载很大一片数据进内存，通常服务器启动要花上好几个小时，就好像开炮前要预热炮管一样。那个时候，每当设计到新的数据，都要考虑数据的落地时机和落地频率，还要考虑数据的访问频度和每次访问的数据大小，其实这些都是应该考虑的，不过在那个年代被放大了，其实数据的落地跟真正的游戏逻辑没有多大关系，在理想服务器下，有没有数据库，对游戏都没什么影响，只要服务器不关闭或者宕机就没有问题。

然后我开始做手游了。

第一次做手游，想脱离原来端游的做法，把自己在做端游时的不满和艳羡的技术都用起来，想走出一片广阔的天空。首先是服务端的语言，之前端游的时候服务器用的 c++和 lua 来写的，一个服务端的代码恨不得有好几十兆，当然不止是游戏逻辑的进程，还有别的进程，加在一起。既然做新游戏了，我自然想耍一耍新的东西，纠结了很久我还是放弃了早已熟悉的 c++和 lua 的架构，开始动手重写一个新的服务器，当时首先想到的是看看别人是怎么尝鲜的，于是在 github 上发现了网易的 pomelo ，由此接触了 nodejs ，当然还看过云风大大的 skynet ，但是我想走的更远，最后纠结了 1 个月是改造 pomelo 还是自己动手写，最后被朋友劝说，一步一步往上爬，才能在最高点乘着叶片往下飞，于是我动手从 0 开始写我的服务器了。花了将近一个月，不停的推翻重构，终于把服务器框架搭好了，那段时间睡觉都在思考服务器的架构，现在想想也是醉了，整体的架构非常精简，而且优美，至少当初我是这么认为了，主要的技术用到了 zmq ，其他的就是兼顾扩展性和灵活性，如果有想了解的朋友可以和我沟通。
然后是发现手机平台由于没有 pc 平台那么强大，所以表现力有限，这不光精简了客户端，同时也减轻了服务端的逻辑，很多人直接用 http 这种短连接来做服务端，这在我做端游的时候是很难想象的，尤其是一些 mmo 的游戏，而端游时代几乎放眼望去 mmo 是最多的，手游有很多不需要这么强连接的游戏，所以短连接也是可以理解的。我先封装了 nodejs 的 tcp socket ，测试性能发现，单个 node 进程 2Wqps ，单包 10bytes 几乎毫无压力，先用了段时间，后来由于客户端的需求，我还是选了折中的协议 websocket ，虽然性能有所下降，但还可以接受。
最后终于到数据库了，由于设计服务器进程的时候，我首先的想法就是不能像以前端游那样，由服务器进程来保存游戏状态，我一定要把状态放进数据库来维护，又不想牵扯冷热数据的问题，而且服务器语言用的是 nodejs ，所以我毫不犹豫的瞄向了 redis 这样的内存数据库，当然有人要争辩 redis 的真正作用，我并不是真的了解它，只是觉得它可爱，小巧，好用。我需要一个读写性能极高的数据库，又不想考虑冷热数据交互，还要求简单易用，当时考虑了 mongodb 跟 redis ，甚至还考察过 leveldb ，最后还是 redis 的简单让我选择了它，“古人”不是说过简单即是美吗，哈哈。基于我服务器的设计， redis 承载的不光是保存数据的任务，还需要参与到游戏逻辑中来，跟我在做端游时完全不同，端游时的数据库是和游戏逻辑分离的，只起到存储和恢复数据的作用，而现在 redis 的作用跟游戏逻辑耦合的更加紧密，如果从这个角度来看，似乎服务器更加复杂了，因为引入了另一个模块来操作游戏逻辑，数据和逻辑杂糅在一起了，但精心的设计和 redis 的简洁性让这件事情看起来没有那么复杂， redis 内建的结构也非常好用，我们用到了 set 、 string 、 hash ，使用了 expire 、 pub/sub 订阅、 key space notification 等等特性。现在我们的游戏逻辑和 redis 已经是水乳交融了，我自己也不知道怎么拆开了。囧。。。另一个需要考虑的问题，是数据的安全性，虽然这个问题不属于游戏逻辑的考虑范围，但本着做人要负责的态度，既然上了床，就要考虑生宝宝的问题。我详细思考和测试过 redis 的备份方案，无论 rdb 还是 aof ，无论是主从还是读写分离，都没有令我觉得完美，也许压根就不存在完美的备份方案，迄今我还在搜寻着，思考着。

我的项目完成度已经接近 80%了，第一次内测可能也就在这一两个月了，花了一年的时间，中间折腾、纠结、痛苦、悲伤、忧郁、喜悦、兴奋过，一路走来，感慨万千。我的故事说完了，也许永远也说不完。写了这么多废话，主要是今天下午有点闲，然后看到帖子写着写着就废话多了，主要目的不是为了拿本书，不过如果寄给我也非常高兴，耽误大家时间了。

建议使用淘宝的国内镜像：--registry=http://registry.npm.taobao.org