游戏与微博的结合，一个微博后台与前端的设计（基于mysql）。（一）

题记-不敢妄言什么微博设计，但是游戏中集成微博与单独的微博设计还是有些区别，正好我有些经验，与大家分享，望大家能少走偏路，不枉我白走了那些偏路。

目前不少游戏都加入了微博系统,当然那几个游戏都有成熟的微博后台作支撑,搞微博植入只需要游戏模块一些功能添加便信手拈来.设计微博更是我从来没想过的事.

大概在大半年前, 老板告诉我想要游戏中植入微博, 这个想法我不做评论, 不过老板是铁了心的要搞, 所以我只能硬着头皮去上.首先就是去查资料,不过对于微博技术细节的东西,网上资料少之又少,只是有些广告性质的文章会提到某某产品用了某某技术来做微博.这距离实际操作还有天壤之别.后来还是静下心来想了想,决定首先从数据存储来入手,选定一个数据存储技术.当然了,新浪微博和QQ微博的我不了解,但是我们的游戏都存在MySQL中,当时网上资料显示关系型数据库来做微博这种玩意,是非常没效率的,NoSql产品倒是随着微博的兴起而越发引人瞩目.当时拟采用 Cassandra,于是粗浅的了解一下这个东东,还没怎么深入的玩,老板就来了,要求我继续使用MySql,原因最重要也最简单的一个,就是我们公司没有NoSql使用经验,老板觉得我从NoSql搞,一没经验二我们产品赶着上线也不够时间.况且在老板眼中,我们的微博定位仅限简单的功能,不需要新浪和QQ那样丰富的功能.(其实微博这玩意,把最简单的功能解决了,其他也就是锦上添花的东西,没技术壁垒了). 好吧, 那我只能基于MySql来设计微博系统了。既然MySql有了现成的技术积累，那我就转而继续设计微博的架构了。说实话，在面对QQ和新浪这么成熟的产品下，让我来设计一个微博系统，心理上我还真是一开始有点怕，到后来呢，我想我也只是麻木了。实际情况呢，这个东西公司人手不够，只有我一个人在做。老板可真够信任我的，我受宠若惊，但是我潜意识里又有种抵触：我自己一个人能搞好这玩意吗？想要这东西，干嘛非要我自己一个人短期内去完成？我明白老板有他的压力，但是有些东西，我觉得强扭的瓜是不甜的。

下面谈谈架构时的经验，我首先面对的事庞大数据量的访问。比如：

一个人的粉丝数量是否封顶？

这个东西显然是必须的，但是上界订多少？对于我们这样的小公司来说，玩家不可能上亿（囧）所以我把每个微博用户的粉丝数存个int就搞定了，但是如果一款世界级的产品，这个数量就必须好好斟酌了。

被粉的人发一条信息，消息的推送？

就从这个看似简单的问题我来说下我们微博实际产品要做到的架构：

后台肯定是与web连接的，要做到web用户与游戏内用户的信息互通。其次就是游戏内跨服的信息互通。很多游戏在跨服方面其实做了很少的工作，我们的游戏也如此（因为常规来讲，跨服操作不是必要设计，所以很多公司也就懒得花时间去做）。而且消息的时效性，虽然我们的实力不能做到A用户发了信息他的粉丝立刻看到，但我们目标是尽量缩短这个时间，但是如果一个人的粉丝比较庞大，这其中要遍历检查每个粉丝是否在线，在线发消息推送，不在线要打标记使得用户上线后可以看到有新信息。因为我们用的是MySql，所以这些数据其实就是考验你怎么设计表。而数据库的查询性能，就我们所能承受的服务器来说，并发查询也就两三千而已，况且我们的其他服务器也是在一个物理服务器上，这导致我不可能使用满载性能。其实当时设计到这里，我真的是有点绝望了，一方面花力气去做，但是现实要考虑资金啊设备啊什么的，一方面我们不可能去单独为了微博去搞一个机组，毕竟我们游戏的服务器还没这个待遇。另一方面我觉得这样设计出来，到时候服务器天天挂，玩家骂没什么，关键是玩家没有从这个服务中得到满足。最后竹篮打水一场空啊，我都不明白我做这东西到底是为了什么，各种迷茫啊那是。

大概这个设计做了三个月，基本模块算是做好了：

一个CacheServer：功能是跟MySql数据库打交道，等于是封装了一个跟MySql通讯的底层。把用户发言信息能cache的全cache（加速信息的提取，因为无法也不能指望每个信息都去Select囧）。

一个ControllerServer：负责与CacheServer通讯，他的职责主要是起到一个服务缓冲区的作用，为了即使再大的数据访问需求量，服务器都不能挂，大不了到了服务器承受能力的话，我把所有请求挡在这一层，等服务器能忙的过来，我再把请求放下去提取数据。这些请求都是有N个Agent发来的。

可扩展的Agent：每个游戏服务器（有的管他叫“线”，就是进游戏选一个服务器进的那个概念）一个Agent，游戏客户端的微博操作会发送给所在服务器的Agent，Agent首先cache起来这些命令，然后根据配置，能知道Agent能负载的最大请求是多少（这个请求，其实是需要根据经验来动态调整的，我把他做成能配置的也方便了调试使用。）Agent会在空闲时候发命令给Controller。

我尽量保持了它的简单性（代码与架构上），在做的过程中逐步体会到了异步，队列，冷热机制，cache这些词语的含义。同时也推荐一篇广为流传的谈微博设计的文章，网上搜下有很多，是新浪架构微博架构师的经验之谈。这篇文章乍看之下对细节没什么帮助，但是当我把这个系统写到一半的时候，从新看看，能学到不少架构时候需要注意的东西。同时也印证一个道理，一篇文章一本书，不是别人说好，你就要硬着头皮看完也附和着说好，一定要自己实际用到的时候才能有体会，有帮助。所以很多人现在看书看各种大牛的书，但是实际上没去用，所以效果很低的。

接着说正题，我们首先来看那个cache，他是有容量限制的，但是我们又希望尽量多的信息存在cache中，因为我希望用户能尽量快的获得自己关注和需要得到的信息，但是又不可能把所有信息都放到cache上让Sql数据库去打酱油，所以这里需要用到数据的换入换出。这里不谈tech谈谈trick。我的思路是：cache的内容根据时间排序，新的顶替掉旧的，但是时间顺序不是指用户发新微博的时间，而是从MySql中提取的数据，每次操作得到新数据就放在一个类似栈的结构上，这个原则是为了减少MySql的查询次数，当然在极端情况下，每个用户所关注的信息极其的不一样，用户量又偏大，我这个设计就hold不住了。

天太冷，打字打不动了，有时间接着分享。。。