码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2016-01-02 12:08:22      阅读:166      评论:0      收藏:0      [点我收藏+]

标签:

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

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。
未完待续~

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

标签:

原文地址:http://www.cnblogs.com/gcczhongduan/p/5094277.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!