主程的晋升攻略(8):数据层的演进(上)

我们用一个做手游的故事来聊聊数据层不断优化提升的演进过程。

 

10:简单设计

有一天,老板突然说做个山寨版的糖果传奇手游,你接到任务后,分析出游戏的交互频率不大,都是点查询,用mysql能简单搞定。对游戏来说,你很少有机会用orcale这种上流货,mysql是物美价廉的选择。建个表,设好主键和索引,你轻松搞定数据库设计,惬意的泡了杯茶边喝边敲代码。

 

这里说的“点查询”,是指基于指定主键的查询,例如查询指定用户的信息,因为是基于指定主键,查询结果有限且较少,点查询的效率非常高。另一种叫“面查询”,是基于主键或索引的范围查询,例如查询昨天所有的订单,这种查询虽然有主键或索引,但结果数量不确定,有时处理不好时会出现严重性能问题。

 

游戏删档内测上线了,用户数不多,请求的响应也很及时,老板拍了拍你的肩膀。

 

100:数据库调优

游戏上线反响不错,精美的画面给了玩家不少惊喜,更多玩家蜂拥而入,你从监控系统上发现mysql的压力有点大,当初只是对数据库表结构做了设计,现在你开始review数据库优化了:创建表时默认的MyISAM存储引擎换成InnoDB存储引擎,修改mysql参数加大InnoDB的cache,不使用事务提交。

 

做了这些优化后,db性能提升明显,整个系统跑得很欢,你又惬意的去泡茶了。

 

1000:分库分表

你们游戏山寨得比较牛叉,用户持续增加,作为有风险意识的你,肯定不会等到系统告警了才去优化,于是你在想更大访问量时怎么办?

 

单台db的性能有极限,必须有扩展到多台db的能力,于是你重新修改了数据库表结构和后台代码,把主键按规则做了分库分表,目前用户增长迅猛,假定单台db存放500万用户,最终可能有上亿用户,那么可能有20台DB,于是你分了32个库,每个库里有32张表,共1024张表。

 

初始时这1024张表都在一台db上,当用户数增加时,分裂成2台、4台、8台、16台。涉及好分库分表策略后,db压力能通过扩容来解决,你放心了。

 

关于读写分离

有不少介绍mysql读写分离已提升mysql并发性能的文章,在游戏项目中用得比较少,主要是读写比例的原因。像网站那种读多写少的应用场景可以采用读写分离,而游戏的读和写差不多多,读写分离的用处不大;而且用户可能是海量的,分多台db是常事,如果分库后再搞读写分离,整个db就过于复杂了。

 

mysql读写分离是基于mysql主从复制功能的,游戏项目如果对数据安全有要求,一般会用mysql主从复制功能做热备。如果项目有GM或经分系统需要直接查询mysql,往往也是在slave上查询,不直接操作master,避免低效查询降低master性能影响业务。这种做法也是OLDP(On-Line Transaction Processing,联机事务处理)和OLAP(On-Line Analytical Processing,联机分析处理)分离的常见做法。

 

10000:缓存

有了分库分表来平滑扩容,项目安稳了较长一段时间,直到某一天,运维说db机器增长比较快,4个月就增加到了64台(master+slave),希望后台能提升单台db的性能,以应对后续的业务增长。

 

OK,你祭出你留的后手——memcached,麻利的操起机械键盘,咔哒咔哒的改起后台的代码,加入缓存逻辑:读的时候从memcached读,如果没有就从mysql查询并写入memcached。写的时候同时写入mysql和memcached。

 

好吧,你终于使用了NoSQL。NoSQL泛指非关系型数据库,是Not Only SQL(有多少人和我一样搞错的~~!)。

 

搞定这个问题后,成本下降了,项目收入可观,拿奖金好happy!

 

未完待续~

 

你可能感兴趣的:(数据库,mysql,memcached,缓存,主程)