谈谈陌陌争霸在数据库方面踩过的坑(排行榜篇) - 推酷
谈谈陌陌争霸在数据库方面踩过的坑(排行榜篇)
为什么大部分网络服务都需要一个数据库在后台支撑整个系统？
这通常是因为大部分系统的一个运行周期都很短，对于传统的网站服务来说，从收到一个 HTTP 请求开始，到终端用户收到这个请求的结果为止，就是一个运行周期。而其间可能处理的数据集是很大的，通常没有时间（甚至没有空间）把所有数据都加载到内存，处理其中涉及的一小部分，然后保存在磁盘上再退出。
当数据量巨大时，任何对数据的操作的算法和数据结构都需要精心设计，这不是随便一个程序员就可以轻松完成的任务。尤其是数据量大到超过内存容量时，很多算法和数据结构对大部分非此领域的程序员来说都是陌生的。本着专业的事情交给专业的人来做的原则，一般系统都会把这部分工作交给独立的数据库来完成。
对数据的操作只有抽象的足够简单，系统才能健壮，这便有了 SQL 语言做一层抽象，让数据管理的工作可以独立出来。甚至于你想牺牲一部分的特性来提高性能，还可以选用近年来流行的各种 NOSQL 数据库。
可在 MMO 游戏服务器领域，事情发生了一点点变化。
数据和业务逻辑是密切相关的，改变非常频繁。MMO 服务器需要持续快速的响应用户的请求。我们几乎不可能把一切数据都放在独立的数据库中，比如玩家在虚拟世界中的位置，以及他所影响的其他玩家的列表；玩家战斗时的各种属性变化，还有和玩家互动的那些 NPC 的状态改变……
最大的矛盾是：MMO 游戏中数据集的改变不再是简单的 SQL 可以表达的东西，不可能交给数据库服务期内部完成。无论什么类型的数据库，都不是为这种应用设计的。如果你硬要套用其它领域的应用模式的话，游戏服务器只能频繁的把各种数据从数据库中读出来，按游戏逻辑做出改变，再写回去。数据库变成了一个很低效的数据中转中心，无论你是否使用内存数据库，都改变不了这个低效的本质。
我听过无数从别的领域转行到游戏领域做开发的程序员设计出来的糟糕系统。他们最终仅仅把数据库当成一个可靠的数据储存点和中转点，认为把所谓重要的数据写进数据库就万事大吉，然后再别扭的从另一个位置把数据从数据库读出来使用。系统中充满了对数据库的奇怪异步回调用来改善系统的反应速度，而系统却始终步履阑珊。能做对已经是极限了，更何况游戏系统不仅仅是输入输出正确就是正确，如果超过了应用的响应时间，一切都是不正确的。
为了让系统健壮，构架师在构架系统时，一定会把系统隔离成不同的模块，并尽量简化模块间的沟通规则。这样你可以单独校验每个模块的质量，必要的时候可以更换。几乎没有人会因为效率或开发方便等原因而把应用代码写到 OS 内核中去跑就是这个道理。
每个模块只对输入它的数据负责，保证输出的正确。通常测试也只对这个正确性负责。同学们最容易忽略的一点是，每个模块都对它输入数据的处理速度有一个上限，也就是它的吞吐量。
一旦输入速度大于处理速度，模块实现的再正确也是百搭。因为永远都不会有输出了。
对于大部分模块，只要内存管够，这都不是问题。实际运作的系统中很少有持续大数据量的输入的，从一个较长的时间看，总的数据输入是小于处理能力的，暂时没能处理的数据堆积在内存就行了。
凡事都有例外。一个健壮的系统都需要对例外做处理。一个工作在 server 模式的数据库是这样解决这个例外的：它会支持查询连接的并发，并发的查询相互间对计算资源的占用是公平的，相互不影响（至少是设计上的理想）。而操作系统或数据库本身会限制并发的连接数，一旦达到最高连接数，系统会拒绝服务；这样就把超过处理能力的输入挡在了模块外面。按这种设计，就不会有输入（只要能抵达）永远没有回应了。
可惜，这样做的代价是，你必须在模块间加入请求失败的处理。一个设计不谨慎的系统最容易在错误处理上栽跟头。他们总是期望任何一个模块都能正确处理上级的请求。
btw, 为什么 12306 的订票系统在高负载的情况下完全不可用？就是这点没处理好。我指的是，一个实现正确的系统，一定不会连网页的刷不出来，不给用户正确的提示，哪怕只是错误提示；也不应该在高负载下，有效处理能力急剧下降。我指的是，一旦用户能进入正常流程，就应该顺利把至少一个环节顺利完成，而不是突然就卡在那里没有任何回应。
快跑题了。我谈到这点，其实是想表达，说的容易，做起来是很难的。下一篇我会写到我们在过年前出的一个事故和这个就有一些关系。
八卦时间：
陌陌劲舞团是陌陌游戏平台上线的第 2 款游戏。我们的陌陌争霸还在开发的时候，这款游戏就打算上线了。我对这个产品有限的了解都是道听途说，所以如果有更清楚内情的同学发现说的不对，也请谅解。对于技术问题，我想八卦的真相就并不那么重要了，有则改之，无则嘉勉。
劲舞团这个品牌原本是属于韩国人的，但这款游戏在国内曾经异常火爆，在国内代理它的久游也就买下来 IP ，自己制作手机版。据我所知，陌陌劲舞团完全是在上海开发的，没韩国人什么事。
这是个比较简单的游戏，至少服务器部分很简单，也就是统计下分数，查查排名，以及解决一下收费问题而已。刨掉这些部分，它就是个单机游戏，根本不需要服务器。
因为劲舞团的品牌名气，以及陌陌巨大的用户群，游戏一上线就在 ios 免费榜飚上去了。如果不是企鹅公司看不顺眼，立刻上线了节奏大师，估计还会在榜单上更火一些。事后证明节奏大师的上线也很仓促，完全是为了打击竞争对手抢着上的，因为后者的服务器也不稳定，很快就挂掉了，完全不像一个大公司应有的质量。
陌陌劲舞团顺利拉来了用户后，第一天服务器就出了状况，重启了几次后完全不解决问题。所以决定停服休整。一停就是三天。当时我就纳闷了，哪有修个小 bug 预计要三天的？这肯定是有结构性问题了。当时我们的项目按计划也就最后半个月的时间了，本来陌陌的人督的我们很紧的，一下子人全飞去了上海。
一周后陌陌劲舞团才重新上线，远超过当初预计的 3 天。事情一解决，陌陌的技术班底，从 CTO 到下面大多数人，全部飞到广州和我们开会，让我们重视服务器稳定性问题。会议内容主要是强调陌陌平台初期导入用户瞬间爆发量巨大，以及了解一下我们的设计细节确保没有大的问题。我所了解到的八卦就是在这段时间听来的。
陌陌劲舞团使用的是 MongoDB 。似乎这玩意很受游戏开发者喜爱。我想主要是因为用起来简单直接吧。游戏从业者如果之前没有别的领域的开发经验，对数据库这东西一知半解的人居多。尤其是从客户端开发过来的人，他们通常的习惯就是看 API 文档，了解怎么用看起来正确就够了。然后上线测试一下，好像也对，工作似乎就结束了。就算有压力测试，也很难做到和生产环境一致。
上线前，据说双方沟通过。陌陌方想确认系统能不能横向扩展，得到的答复是可以：加硬件即可。我想陌陌劲舞团开发方的思路是这样的：我们的服务器系统很简单，不都是过一下数据库么？MongoDB 是被很多人验证过的，不会在这么简单的业务中出问题吧。至于负载，不是还有 mongos 么？放心啦，没事的。
最终的直接问题出在排行榜上。当有两万人在线时（没错，才两万人而已），大量用户的排行榜查询阻塞了数据库。导致不仅仅是排行榜刷不出来，连冲值业务也受到了影响。土豪们充不进去钱，谈什么玩游戏啊。最终产生了雪崩，整个数据库都不正常使得游戏系统工作不起来。
为啥用了这么长时间才修好这个 bug ？
负责陌陌劲舞团的服务器开发的人在项目做完就离职了。想想一个设计有问题的系统交给非设计者维护有多糟糕吧？任何清醒的程序员都知道，这个时候即使是重写也比改问题简单。陌陌的同学做了个正确的决定，直接派自己的人驻留在上海，把服务器重新写了一遍。
陌陌的技术背景是 Redis 的，他们的系统用 redis 构建，所以重写就用了 redis 取代 mongodb 。写到这里，我完全没有 redis 和 mongodb 谁好谁差的意思。关键在人，你对什么熟悉就用什么，哪种数据库都能对付这点小业务，关键看你能不能用对。
Redis 里正好有一个有序集(Sorted Set) 的数据结构，你用 ZADD 插入完数据后，它就天然有序了。这个插入是 O( M * log(N)) 的时间复杂度，基本可以满足需求。而用 ZRANGE 查询榜单仅需 O(log(N)+M) 的时间复杂度。
那么使用 Redis ，利用 sorted set 做排行榜系统是我们的唯一选择么？绝对不是。我们也不可能为了这个特性必须选择 redis 做数据库。但这个例子可以说明：如果数据库提供内在的特性可以对数据集做一些操作，我们就直接用，但需要了解这种操作的性能。它需要和整个系统对它的性能期望匹配。
陌陌劲舞团使用 mongodb 内置的排序功能去做排行榜本也不是大问题。或许仅仅只是实现的人对 mongo 不熟悉造成的性能低下。这些随着系统重建已经无法深究了。但核心问题是，仅仅一个排行榜系统的错误实现为何会影响整个系统的稳定性？
下面就是我的猜测了：
许多程序员为了提高数据库的吞吐量，并不是一个事务就给数据库建一个连接，用完就关掉的。因为新建 TCP 连接是个开销较大的操作。维持太多连接对系统也是一个开销。同学们喜欢做一个叫做连接池的东西，在系统其它部分和数据库对接的地方走这个连接池。只要一个旧有连接没有断开，就一直把对数据库的请求通过固定连接发给数据库，等待返回。
在数据库的吞吐量满足系统需求的时候，这个模块很容易实现正确。但一旦超出需求，连接池上的数据就会越积越多，数据库查询越来越慢。而调用数据库的模块却不觉得这是问题。
正确的行为应该是让连接池快速反馈，断开并扔掉不可能处理完的请求，让请求方把这个不能处理的错误反馈到上个环节，直到流量被限制在合理的范围内。整个系统才能不至于崩溃。当错误被迫反馈到玩家那里时，他顶多看到的是查询失败，而不太会影响到别的功能。
陌陌争霸怎样做排行榜的？
在上一篇里就有同学问道，如果你们不用数据库，怎么做排行榜呢？ 其实我在上一篇正文里就有解答：
“服务器只是在不断的创造新数据并让这些数据在内存中流通而已，它没有任何需要从外部读取数据。如果内存无限大，且服务器永远不会当机，数据库这个设施没有存在的必要。”
排行榜单也是数据之一，游戏服务器开服一刻起，没有任何玩家有排名信息。随着玩家名次更替，榜单才逐步形成。我们只需要在玩家分数变化的时候同步榜单的变化即可。而玩家查询仅仅是取走有序的榜单而已。
你看，这个过程和数据库无关不是？需要设计的是调整榜单的算法，和榜单的数据结构以保证维持榜单的性能足够强就好了。因为玩家名词更替的频率远小于玩家网络包的频率，那么这个模块的处理能力所需要的下限很容易满足。我们不用考虑处理不过来的情况。
针对陌陌争霸我们是这样做的：
陌陌争霸中用于排名的分数区间不大，也就是 0 分到 5000 分。而参与排名的人数众多，数以百万计。对百万用户做插入排序，每个插入即使是 O(N) 的也不可接受。可事实是大量玩家的分数相同，都是并列排名的。所以我们只需要做 5000 个桶，每个桶里仅记录这个分数有多少个人就可以了。
当玩家分数变迁，把原来的桶减一，新的桶加一。这个操作就是 O(1) 的。
而排行榜的查询仅需要把当前分数靠前的桶累加，就能获知查询者的名次。对于上百万玩家，看到哪些人和你并列的人的名字是没有意义的。这个查询虽然是 O(n) 复杂度，但 n 只有区区 5000 ，还可以做 cache 以应对查询频率远高于更新频率的情况。
真正需要精确知道人名的是榜单的前 200 个人，而对前 200 个人做插入排序也很快，所以并不会造成性能问题。
我们在系统的单点做排行榜的维持，完全没有外部数据库操作，它只是一小段操作普通内存结构的 c 代码。而这个单点远远成为不了整个系统的热点。
我们在系统临时退出时，把已经排好的榜单落地，下次启动的时候恢复。但也不必完全信任落地的数据，可以用离线脚本检索整个数据库重新生成一份正确的榜单。所以数据库中的榜单只是被 cache 起来而已，系统运行期间是不需要写入数据库的，也不用担心数据丢失。
好吧，还是没谈到我们自己踩的坑，就又到了吃饭时间 :( 。明天我将写写陌陌争霸在运营期间遇到的第一起数据库事故，它和 mongos 有关。同时也会谈谈我们在代理狂刃期间帮狂刃填的一些和 mongodb 有关的坑。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致登录房天下账户
没有房天下通行证？
环一线城市房价蹿升争议 政策该踩刹车还是去库存
中国广播网&&&&
上海、深圳等一线城市近来出台政策，抑制房价过快上涨。随之而来的是环一线城市的房价迅速蹿高，地方政府为此收紧房地产政策，由此引发争议：政策该踩刹车还是趁机去库存?
原标题：环一线城市房价蹿升引发争议：政策该踩刹车还是趁机去库存?央广网北京5月9日 上海、深圳等一线城市近来出台政策，抑制房价过快上涨。随之而来的是环一线城市的房价迅速蹿高，地方政府为此收紧房地产政策，由此引发争议：政策该踩刹车还是趁机去库存?新数据显示，上海、深圳出台房价调控政策&满月&后，两地楼市交易量都出现50%左右的回落。与此同时，环一线城市的楼市量价接力&蹿升&，势头还蔓延到附近的二三线城市。在上个月住宅价格环比涨幅居前十位的城市中，环一线城市就占了80%。另外，毗邻一线城市的省份如广东、浙江、河北等城市，房价收入比分别以9.4年、8.5年、7.3年领先全国。对这组数据，正在看房的北京市民张先生有体会：张先生：我们去了一下河北省怀来市，这是北京周边。去了之后发现有很多从北京过来看房的人。我和房产中介聊了一下，发现这块近一直都很热。相比一线城市，为什么它周边城市的房价涨幅能后来居上呢?中原地产首席分析师张大伟分析，环一线城市房产的预期收益更大。另外，一线城市的限购政策也把部分需求挤压到周边城市：专家：首先一线城市经过几轮的价格上涨，房价都是处于很高的位置。一线城市的辐射区，价格大部分还是在一万多，多两万多。在溢出性的改善、投资和刚需等多方面影响下，一线城市的辐射区变得火热了。第二个原因是政策因素，即使是在没有政策调控的时候，一线城市也是限购的，但是一线城市的周围区域没有限购限贷的约束。需求外溢加上政策调控，让二三线城市的楼市升温成为普遍现象。数据显示，4月份二线城市合计土地出让676宗，土地出让金超过1224亿元，环比上涨 29%，成交楼面均价和平均溢价率都创下高历史纪录。但一线城市4月成交土地只有11宗，北京、深圳没有成交。张大伟认为，无论哪类城市，房价骤热骤冷都不是正常现象，需要政策调控：专家：那么过快的上涨和过快的下调同样不是健康的状态。所以现在来看，未来房地政策的方向肯定是托底盖帽并进。正如专家所说，河北环京四县市，长三角地区的合肥、南京，毗邻深圳的惠州等城市开始收紧政策。河北廊坊出台9条稳控楼市措施，对下辖的三河等地实施限购;南京市宣布商品住宅项目价格将设&涨停区间&，根据房产价格设置不同幅度的年化高涨幅;惠州则规定，小微贷款及消费贷额度要变低。从另一方面来看，这些地方政策的变化也引发了争议：我国楼市仍有去库存目标，大多数二三四线城市的任务尤其严峻。那么，面对一线城市转移的购房需求，环一线城市为什么不趁机去库存，反而在政策上踩了刹车呢?根据去年房地产企业披露的年报，137家上市房企存货总计超过3万亿元，以绿地为首的A股5大房企存货占比超过42%，不少企业面临存货周转次数减少、存货周转天数变长的问题。中国房地产经理人联盟秘书长陈云峰认为，在这样的背景下，环一线城市的刹车踩得有点急：陈云峰：我觉得在二线城市房价热起来之后，不要急于出台措施。如果观察三个月左右，成交量仍然比较大，而且房价也出现大幅度的上涨，我觉得可以考虑采取一些降温的措施。成交量大或者房价上涨以什么为标准呢?我觉得成交量环比或同比增长超过30%，去库存的措施减弱一下就可以了。在陈云峰看来，借助一线城市的外溢需求，带动周围二三线、甚至四线城市去库存是个好机会。正常的需求推动房价上涨，不会影响市场健康：陈云峰：一线城市热销，传导给了二线城市，二线城市再过三四个月也会传导给三四线城市。前一段时间整个市场还是被压抑的。这样的话我们还需要判断一下，比如推动成交量上升的都是正常的刚性需求、改善性需求和正常投资需求，都没有什么大惊小怪的。但有专家不认同这个观点，他认为房价波动幅度过大都要调控，外溢需求不能成为一线周边城市去库存的主要政策。如果没有配套产业，这些城市楼市的繁荣也只是暂时的：该专家表示这不能成为三四线城市去库存的主要政策，因为三四线城市如果没有产业转移，人口不可能因为一线城市收紧限购就回流到三四线城市。总体而言这是一个系列政策，不能期待一二线城市降温来带动三四线城市，有可能一二线城市降温了，如果产业没有转移到三四线，整个市场就都会降温。
房天下APP优惠多，速度快
买好房，就上房天下
关注房天下官方微信
新房、二手房、租房，特价房大平台！
29519.00元／㎡
芍药居北里
88005.00元／㎡
60㎡混搭风格二室一厅,多彩的设计让你一秒入夏
斑斓与粗犷的结合 130平简约装
内敛雅致 130平风格雅居
21世纪经济报道
每日经济新闻
财政部将发文推进PPP资产证券化 2年期限设定望放宽
北京“商改住”新政利剑出鞘 绿地子公司顶风作案被重罚
八客网-企业信息免费推广
京商住房销售遭遇"过山车"
李居明、曹振霆先生流年飞星图解：鸡年运程之九紫星
2017年卫浴行业消费报告 新一轮增长周期已经开始
中国周易大师曹振霆：家居风水之儿童房
2017年家具行业消费数据报告 3分钟读懂行业！
大家都在关注
买房牛人邦介绍：
买房套路深，我要回农村
房天下楼盘点评介绍：
买房走捷径--全国购房者真实买房经历，尽在房天下楼盘点评
鬼斗介绍：
楼市评论解读，房产知识解析
中国网地产中国介绍：
中国互联网新闻中心主办的国家级重点新闻网站的房地产信息平台
美房网投资俱乐部介绍：
美房网投资俱乐部，专业的投资分析。
央行清晰释放加息信号?一大批楼市调控政策正在加码
价格涨得慢房子不好卖:最后的套现机会要抓住
刚需买房看交通 房山地铁新线路即将通车
多地调控政策再加码 限售将成调控新政“标配”
记录 |大浪淘沙,那些曾叱咤风云的“地产一哥”今何在?
楼盘热评榜
72000元/平方米
12000元/平方米
54000元/平方米
2500万元/套
Copyright &
北京拓世宏业科技发展有限公司
Beijing Tuo Shi Hong Ye Science&Technology Development Co.,Ltd 版权所有
客服电话：400-850-8888
违法和不良信息举报电话：010-
举报邮箱：答案长度必须超过10个字，请勿发布无效或违法言论。
（共1个回答）
理论上考科目三需在科目二通过后考试，但并无规定具体在科目二通过后几天进行，只规定了科目二的考试需在科目一通过后的满20天才可预约考试， 要在科目一通过后的满30
科目二要在科目一通过后20日后预约，科目三要在科目一通过后30日后预约。只要满足这个条件就行。 没有科目四，都是科目三内容。科目三实际道路驾驶和安全文明驾驶常识
如果你自己预约了，那就是按照预约的时间考。如果你没有预约，科目2一般是跟随驾校统一去考试的，一般一所驾校会和车管所统一安排一个月1-2次的考试。所以你问问你们驾
科目4考完后，一般要等15天左右带上驾校的发票到驾校领取。
没有限制，如果你没时间考。你不约考就可以了，继续排队，这样好点，如果约考不去，算是不及格的
科目二考什么?在驾驶员考试中科目二考试主要考什么?驾考改革已经两年了，所以科目二现在只考五项。那么科目二有那五项考试组成?下面看看元贝驾考的小编给大家整理的科目
桩考不用补考的，补考费的话问一下你报名的驾校，要看你是不是直接去考试场地，需不需要租车的，考试前要不要买2把先练一下什么的
自己可以在网上预约阿。不过你约其他考场还有重新模拟不换算，，而且教练多半会不爽
倒车入库、坡道起步和定点停车、侧方停车、曲线行驶、直角转弯五项。
夜考很难抽到的，5%而已，我以为被抽到的机会不大，虽然我第一次正好抽到，第一次路考夜考没过。灯光考试一般不会错的，仔细听就行。起步的十分要仔细点，如果你起步十分
大家还关注
(C)2017 列表网&琼ICP备号-12&增值电信业务经营许可证B2-&有一次坐的车到地下车库，问她是不是踩了离合，她说肯定要踩的，否则要熄火。但也有朋友说只踩刹车就行了。他们谁说的正确？如果要踩离合，坡很长的话一直踩离合对车的损害大吗？
一、车子只要在动（往前或者往后行驶中）就不会熄火，和踩不踩离合器没关系。
二、高速行驶不能空档滑行，太不安全了。低速情况下，短时间空档滑行是正常的——换档过程就是短暂的空档滑行！对吧！哈哈哈！
三、速度快的情况下，要先踩刹车，后踩离合器；速度慢的情况下，要同时踩刹车和离合器，特别是在一、二档情况下，因为先踩刹车，一脚下去车子就不会动了，肯定熄火。不需要停车的情况下，是先踩离合器，然后用刹车控制速度——空档滑行时常用。
四、车子在行使状态下，如果不踩离合器，踩刹车就熄火，那么车子是有故障了，要赶快去修理。
其他答案（共8个回答）
车辆的能力（能不能控制好车辆）要是能控制车辆菜不睬都是一样的。
新手一般都是这个问题！
不光是下坡，正常行驶的时候需要减速时，按照以下有三种情况操作即可！
1、只要把右脚抬起松开油门（就可减速）。
2、踩下制动...
对于电喷车来说，当然是带档滑行即省油，又安全。带档的时候，由于是车子带着发动机转，一滴油都不用。如果空档滑行，发动机反而要喷油，来维持基本的怠速运转。
刹车时要不要踩离合器，不决定于几档，而是决定于车速，一般行车中踩刹车无需踩离合器，但当车速急剧下降，造成脱档、甚至要熄火了就应踩离合器了。紧急刹车时，停车是第一...
上坡停车是要先踩离合的，踩离合后车子还会向前冲一小段距离。先踩刹车很容易憋死发动机。
平路也是这样。先放到空档，或踩下离合。
“先刹后离”是指的高速...
根据车速选个合适的档挂上就行，再加上刹车（不踩离合）。
大家还关注
确定举报此问题
举报原因(必选)：
广告或垃圾信息
激进时政或意识形态话题
不雅词句或人身攻击
侵犯他人隐私
其它违法和不良信息
报告，这不是个问题
报告原因(必选)：
这不是个问题
这个问题分类似乎错了
这个不是我熟悉的地区云风的 BLOG: 谈谈陌陌争霸在数据库方面踩过的坑(排行榜篇)
我的图书馆
云风的 BLOG: 谈谈陌陌争霸在数据库方面踩过的坑(排行榜篇)
为什么大部分网络服务都需要一个数据库在后台支撑整个系统？这通常是因为大部分系统的一个运行周期都很短，对于传统的网站服务来说，从收到一个 HTTP 请求开始，到终端用户收到这个请求的结果为止，就是一个运行周期。而其间可能处理的数据集是很大的，通常没有时间（甚至没有空间）把所有数据都加载到内存，处理其中涉及的一小部分，然后保存在磁盘上再退出。当数据量巨大时，任何对数据的操作的算法和数据结构都需要精心设计，这不是随便一个程序员就可以轻松完成的任务。尤其是数据量大到超过内存容量时，很多算法和数据结构对大部分非此领域的程序员来说都是陌生的。本着专业的事情交给专业的人来做的原则，一般系统都会把这部分工作交给独立的数据库来完成。对数据的操作只有抽象的足够简单，系统才能健壮，这便有了 SQL 语言做一层抽象，让数据管理的工作可以独立出来。甚至于你想牺牲一部分的特性来提高性能，还可以选用近年来流行的各种 NOSQL 数据库。可在 MMO 游戏服务器领域，事情发生了一点点变化。数据和业务逻辑是密切相关的，改变非常频繁。MMO 服务器需要持续快速的响应用户的请求。我们几乎不可能把一切数据都放在独立的数据库中，比如玩家在虚拟世界中的位置，以及他所影响的其他玩家的列表；玩家战斗时的各种属性变化，还有和玩家互动的那些 NPC 的状态改变……最大的矛盾是：MMO 游戏中数据集的改变不再是简单的 SQL 可以表达的东西，不可能交给数据库服务期内部完成。无论什么类型的数据库，都不是为这种应用设计的。如果你硬要套用其它领域的应用模式的话，游戏服务器只能频繁的把各种数据从数据库中读出来，按游戏逻辑做出改变，再写回去。数据库变成了一个很低效的数据中转中心，无论你是否使用内存数据库，都改变不了这个低效的本质。我听过无数从别的领域转行到游戏领域做开发的程序员设计出来的糟糕系统。他们最终仅仅把数据库当成一个可靠的数据储存点和中转点，认为把所谓重要的数据写进数据库就万事大吉，然后再别扭的从另一个位置把数据从数据库读出来使用。系统中充满了对数据库的奇怪异步回调用来改善系统的反应速度，而系统却始终步履阑珊。能做对已经是极限了，更何况游戏系统不仅仅是输入输出正确就是正确，如果超过了应用的响应时间，一切都是不正确的。为了让系统健壮，构架师在构架系统时，一定会把系统隔离成不同的模块，并尽量简化模块间的沟通规则。这样你可以单独校验每个模块的质量，必要的时候可以更换。几乎没有人会因为效率或开发方便等原因而把应用代码写到 OS 内核中去跑就是这个道理。每个模块只对输入它的数据负责，保证输出的正确。通常测试也只对这个正确性负责。同学们最容易忽略的一点是，每个模块都对它输入数据的处理速度有一个上限，也就是它的吞吐量。一旦输入速度大于处理速度，模块实现的再正确也是白搭。因为永远都不会有输出了。对于大部分模块，只要内存管够，这都不是问题。实际运作的系统中很少有持续大数据量的输入的，从一个较长的时间看，总的数据输入是小于处理能力的，暂时没能处理的数据堆积在内存就行了。凡事都有例外。一个健壮的系统都需要对例外做处理。一个工作在 server 模式的数据库是这样解决这个例外的：它会支持查询连接的并发，并发的查询相互间对计算资源的占用是公平的，相互不影响（至少是设计上的理想）。而操作系统或数据库本身会限制并发的连接数，一旦达到最高连接数，系统会拒绝服务；这样就把超过处理能力的输入挡在了模块外面。按这种设计，就不会有输入（只要能抵达）永远没有回应了。可惜，这样做的代价是，你必须在模块间加入请求失败的处理。一个设计不谨慎的系统最容易在错误处理上栽跟头。他们总是期望任何一个模块都能正确处理上级的请求。btw, 为什么 12306 的订票系统在高负载的情况下完全不可用？就是这点没处理好。我指的是，一个实现正确的系统，一定不会连网页的刷不出来，不给用户正确的提示，哪怕只是错误提示；也不应该在高负载下，有效处理能力急剧下降。我指的是，一旦用户能进入正常流程，就应该顺利把至少一个环节顺利完成，而不是突然就卡在那里没有任何回应。快跑题了。我谈到这点，其实是想表达，说的容易，做起来是很难的。下一篇我会写到我们在过年前出的一个事故和这个就有一些关系。八卦时间：陌陌劲舞团是陌陌游戏平台上线的第 2 款游戏。我们的陌陌争霸还在开发的时候，这款游戏就打算上线了。我对这个产品有限的了解都是道听途说，所以如果有更清楚内情的同学发现说的不对，也请谅解。对于技术问题，我想八卦的真相就并不那么重要了，有则改之，无则嘉勉。劲舞团这个品牌原本是属于韩国人的，但这款游戏在国内曾经异常火爆，在国内代理它的久游也就买下来 IP ，自己制作手机版。据我所知，陌陌劲舞团完全是在上海开发的，没韩国人什么事。这是个比较简单的游戏，至少服务器部分很简单，也就是统计下分数，查查排名，以及解决一下收费问题而已。刨掉这些部分，它就是个单机游戏，根本不需要服务器。因为劲舞团的品牌名气，以及陌陌巨大的用户群，游戏一上线就在 ios 免费榜飚上去了。如果不是企鹅公司看不顺眼，立刻上线了节奏大师，估计还会在榜单上更火一些。事后证明节奏大师的上线也很仓促，完全是为了打击竞争对手抢着上的，因为后者的服务器也不稳定，很快就挂掉了，完全不像一个大公司应有的质量。陌陌劲舞团顺利拉来了用户后，第一天服务器就出了状况，重启了几次后完全不解决问题。所以决定停服休整。一停就是三天。当时我就纳闷了，哪有修个小 bug 预计要三天的？这肯定是有结构性问题了。当时我们的项目按计划也就最后半个月的时间了，本来陌陌的人督的我们很紧的，一下子人全飞去了上海。一周后陌陌劲舞团才重新上线，远超过当初预计的 3 天。事情一解决，陌陌的技术班底，从 CTO 到下面大多数人，全部飞到广州和我们开会，让我们重视服务器稳定性问题。会议内容主要是强调陌陌平台初期导入用户瞬间爆发量巨大，以及了解一下我们的设计细节确保没有大的问题。我所了解到的八卦就是在这段时间听来的。陌陌劲舞团使用的是 MongoDB 。似乎这玩意很受游戏开发者喜爱。我想主要是因为用起来简单直接吧。游戏从业者如果之前没有别的领域的开发经验，对数据库这东西一知半解的人居多。尤其是从客户端开发过来的人，他们通常的习惯就是看 API 文档，了解怎么用看起来正确就够了。然后上线测试一下，好像也对，工作似乎就结束了。就算有压力测试，也很难做到和生产环境一致。上线前，据说双方沟通过。陌陌方想确认系统能不能横向扩展，得到的答复是可以：加硬件即可。我想陌陌劲舞团开发方的思路是这样的：我们的服务器系统很简单，不都是过一下数据库么？MongoDB 是被很多人验证过的，不会在这么简单的业务中出问题吧。至于负载，不是还有 mongos 么？放心啦，没事的。最终的直接问题出在排行榜上。当有两万人在线时（没错，才两万人而已），大量用户的排行榜查询阻塞了数据库。导致不仅仅是排行榜刷不出来，连冲值业务也受到了影响。土豪们充不进去钱，谈什么玩游戏啊。最终产生了雪崩，整个数据库都不正常使得游戏系统工作不起来。为啥用了这么长时间才修好这个 bug ？负责陌陌劲舞团的服务器开发的人在项目做完就离职了。想想一个设计有问题的系统交给非设计者维护有多糟糕吧？任何清醒的程序员都知道，这个时候即使是重写也比改问题简单。陌陌的同学做了个正确的决定，直接派自己的人驻留在上海，把服务器重新写了一遍。陌陌的技术背景是 Redis 的，他们的系统用 redis 构建，所以重写就用了 redis 取代 mongodb 。写到这里，我完全没有 redis 和 mongodb 谁好谁差的意思。关键在人，你对什么熟悉就用什么，哪种数据库都能对付这点小业务，关键看你能不能用对。Redis 里正好有一个有序集(Sorted Set) 的数据结构，你用 ZADD 插入完数据后，它就天然有序了。这个插入是 O( M * log(N)) 的时间复杂度，基本可以满足需求。而用 ZRANGE 查询榜单仅需 O(log(N)+M) 的时间复杂度。那么使用 Redis ，利用 sorted set 做排行榜系统是我们的唯一选择么？绝对不是。我们也不可能为了这个特性必须选择 redis 做数据库。但这个例子可以说明：如果数据库提供内在的特性可以对数据集做一些操作，我们就直接用，但需要了解这种操作的性能。它需要和整个系统对它的性能期望匹配。陌陌劲舞团使用 mongodb 内置的排序功能去做排行榜本也不是大问题。或许仅仅只是实现的人对 mongo 不熟悉造成的性能低下。这些随着系统重建已经无法深究了。但核心问题是，仅仅一个排行榜系统的错误实现为何会影响整个系统的稳定性？下面就是我的猜测了：许多程序员为了提高数据库的吞吐量，并不是一个事务就给数据库建一个连接，用完就关掉的。因为新建 TCP 连接是个开销较大的操作。维持太多连接对系统也是一个开销。同学们喜欢做一个叫做连接池的东西，在系统其它部分和数据库对接的地方走这个连接池。只要一个旧有连接没有断开，就一直把对数据库的请求通过固定连接发给数据库，等待返回。在数据库的吞吐量满足系统需求的时候，这个模块很容易实现正确。但一旦超出需求，连接池上的数据就会越积越多，数据库查询越来越慢。而调用数据库的模块却不觉得这是问题。正确的行为应该是让连接池快速反馈，断开并扔掉不可能处理完的请求，让请求方把这个不能处理的错误反馈到上个环节，直到流量被限制在合理的范围内。整个系统才能不至于崩溃。当错误被迫反馈到玩家那里时，他顶多看到的是查询失败，而不太会影响到别的功能。陌陌争霸怎样做排行榜的？在上一篇里就有同学问道，如果你们不用数据库，怎么做排行榜呢？ 其实我在上一篇正文里就有解答：“服务器只是在不断的创造新数据并让这些数据在内存中流通而已，它没有任何需要从外部读取数据。如果内存无限大，且服务器永远不会当机，数据库这个设施没有存在的必要。”排行榜单也是数据之一，游戏服务器开服一刻起，没有任何玩家有排名信息。随着玩家名次更替，榜单才逐步形成。我们只需要在玩家分数变化的时候同步榜单的变化即可。而玩家查询仅仅是取走有序的榜单而已。你看，这个过程和数据库无关不是？需要设计的是调整榜单的算法，和榜单的数据结构以保证维持榜单的性能足够强就好了。因为玩家名词更替的频率远小于玩家网络包的频率，那么这个模块的处理能力所需要的下限很容易满足。我们不用考虑处理不过来的情况。针对陌陌争霸我们是这样做的：陌陌争霸中用于排名的分数区间不大，也就是 0 分到 5000 分。而参与排名的人数众多，数以百万计。对百万用户做插入排序，每个插入即使是 O(N) 的也不可接受。可事实是大量玩家的分数相同，都是并列排名的。所以我们只需要做 5000 个桶，每个桶里仅记录这个分数有多少个人就可以了。当玩家分数变迁，把原来的桶减一，新的桶加一。这个操作就是 O(1) 的。而排行榜的查询仅需要把当前分数靠前的桶累加，就能获知查询者的名次。对于上百万玩家，看到哪些人和你并列的人的名字是没有意义的。这个查询虽然是 O(n) 复杂度，但 n 只有区区 5000 ，还可以做 cache 以应对查询频率远高于更新频率的情况。真正需要精确知道人名的是榜单的前 200 个人，而对前 200 个人做插入排序也很快，所以并不会造成性能问题。我们在系统的单点做排行榜的维持，完全没有外部数据库操作，它只是一小段操作普通内存结构的 c 代码。而这个单点远远成为不了整个系统的热点。我们在系统临时退出时，把已经排好的榜单落地，下次启动的时候恢复。但也不必完全信任落地的数据，可以用离线脚本检索整个数据库重新生成一份正确的榜单。所以数据库中的榜单只是被 cache 起来而已，系统运行期间是不需要写入数据库的，也不用担心数据丢失。好吧，还是没谈到我们自己踩的坑，就又到了吃饭时间 :( 。明天我将写写陌陌争霸在运营期间遇到的第一起数据库事故，它和 mongos 有关。同时也会谈谈我们在代理狂刃期间帮狂刃填的一些和 mongodb 有关的坑。
TA的最新馆藏