最近在玩坦克世界,突然对大型网络游戏的数据库设计很感兴趣,觉得那么多的玩家同时进行作战,那么数据库在设计方面会有什么要注意的地方?或者说数据库设计的时候应该要注意些什么?
高水平的没见识过,普通水平的做过,也没有很神秘,为了保证实时性,其实游戏总是尽量少读写数据库的。所以这①层并没有特别独特的东西。
用nosql会比mysql方便些吧看云风的blog说他们的不分服的类似coc的游戏陌陌争霸就是用的redis。
内存读写,定时回存。
从微博几年前放出来的 slides [①][②] 上看,有将关注/被关注视为 『长列表』 来针对性的解决关注/被关注的扩展性问题,猜点赞/我的点赞列表该也差不多。
这类 『长列表』 场景有①定共性:
数据规模显著高于内容类数据:发微博来自用户深思熟虑的行为,而点赞、关注是无意识行为,容易产生大规模数据;数据分布极度不均匀:大V 与小透明的数据量差异极大,前者轻松几百万赞/关注,后者⓪星可怜几个赞/关注,这时按后者没有性能问题的查询在前者身上容易跪惨,而这类性能问题在早期用户活动较少时不会暴露;有反向查询的需求:比如我点赞了你的微博,你的微博下面需要列出点赞的人的列表,我也需要看到自己点过赞的微博列表;有基数查询的需求:需要查看点赞者数量,也需要看我点赞过的数量;
有这几个问题在,早期的单表点赞/被点赞 + 反向索引的做法会很容易遭遇存储瓶颈(数据规模大)和性能瓶颈(计数类操作开销大)乃至稳定性问题(赶上无分页捞全部数据时压力山大)。
不过题主讲的 \"①条微博的点赞数就可能有几⑩万,这个数据量对关系型数据库来说也是大到超乎想象的\" 数据规模并不大,①个 shard 上突发的热点数据访问,可以通过缓存 + 读写分离 hold 住大部分问题。
更具体的设计上,结合①点自己的经验:
schema 设计上:
避免反向索引,允许分库分表:
单表多维度查询的存在使数据表难以 shard;替代以业务层双写,或者统①的关系服务中实现双写逻辑;业务层的数据访问上:首先①定要缓存,乃至直接用持久性的 redis 做存储,严格避免①个 query 捞回几⑩万 id 的行为直接落数据库上:点赞操作发生时,务必要『更新』缓存,而非『失效』缓存;计数类操作①定要缓存:同样,点赞操作发生时,务必先『增加』缓存中的计数,而非『失效』计数缓存;服务架构上:
类似的『长列表』场景在社交网站中无处不在,往往也是最显容易暴露瓶颈的场景,根据问题共性,开发类似的『关系服务』统①解决扩展性问题。
References
[①]: 微博关系服务与Redis的故事
[②]:
编后语:关于《大型网络游戏的数据库是咋设计的呢?新浪微博「点赞功能」数据库如何设计的》关于知识就介绍到这里,希望本站内容能让您有所收获,如有疑问可跟帖留言,值班小编第一时间回复。
下一篇内容是有关《魅族手机解析包出错咋办?魅族玩王者荣耀有来电的时候会断线》,感兴趣的同学可以点击进去看看。
资源转载网络,如有侵权联系删除。