大型网络游戏的数据库是咋设计的呢？新浪微博「点赞功能」数据库如何设计的

发表时间：2018-02-06 14:48:02 作者： 来源： 浏览：次

在上一篇文章中，小编为您详细介绍了关于《台湾冠兴板抓烟机天车向右行时放掉操纵杆为什么样它要向左自动复位？两岸和平统一之后龙芯还有什么样存在的意义》相关知识。本篇中小编将再为您讲解标题大型网络游戏的数据库是咋设计的呢？新浪微博「点赞功能」数据库如何设计的。

最近在玩坦克世界，突然对大型网络游戏的数据库设计很感兴趣，觉得那么多的玩家同时进行作战，那么数据库在设计方面会有什么要注意的地方？或者说数据库设计的时候应该要注意些什么？

高水平的没见识过，普通水平的做过，也没有很神秘，为了保证实时性，其实游戏总是尽量少读写数据库的。所以这①层并没有特别独特的东西。

用nosql会比mysql方便些吧看云风的blog说他们的不分服的类似coc的游戏陌陌争霸就是用的redis。

内存读写，定时回存。

从微博几年前放出来的 slides [①][②] 上看，有将关注/被关注视为『长列表』来针对性的解决关注/被关注的扩展性问题，猜点赞/我的点赞列表该也差不多。

这类『长列表』场景有①定共性：

数据规模显著高于内容类数据：发微博来自用户深思熟虑的行为，而点赞、关注是无意识行为，容易产生大规模数据；数据分布极度不均匀：大V 与小透明的数据量差异极大，前者轻松几百万赞/关注，后者⓪星可怜几个赞/关注，这时按后者没有性能问题的查询在前者身上容易跪惨，而这类性能问题在早期用户活动较少时不会暴露；有反向查询的需求：比如我点赞了你的微博，你的微博下面需要列出点赞的人的列表，我也需要看到自己点过赞的微博列表；有基数查询的需求：需要查看点赞者数量，也需要看我点赞过的数量；

有这几个问题在，早期的单表点赞/被点赞 + 反向索引的做法会很容易遭遇存储瓶颈（数据规模大）和性能瓶颈（计数类操作开销大）乃至稳定性问题（赶上无分页捞全部数据时压力山大）。

不过题主讲的 \"①条微博的点赞数就可能有几⑩万，这个数据量对关系型数据库来说也是大到超乎想象的\" 数据规模并不大，①个 shard 上突发的热点数据访问，可以通过缓存 + 读写分离 hold 住大部分问题。

更具体的设计上，结合①点自己的经验：

schema 设计上：

避免反向索引，允许分库分表：

单表多维度查询的存在使数据表难以 shard；替代以业务层双写，或者统①的关系服务中实现双写逻辑；业务层的数据访问上：首先①定要缓存，乃至直接用持久性的 redis 做存储，严格避免①个 query 捞回几⑩万 id 的行为直接落数据库上：点赞操作发生时，务必要『更新』缓存，而非『失效』缓存；计数类操作①定要缓存：同样，点赞操作发生时，务必先『增加』缓存中的计数，而非『失效』计数缓存；服务架构上：

类似的『长列表』场景在社交网站中无处不在，往往也是最显容易暴露瓶颈的场景，根据问题共性，开发类似的『关系服务』统①解决扩展性问题。

References

[①]: 微博关系服务与Redis的故事

[②]:

编后语：关于《大型网络游戏的数据库是咋设计的呢？新浪微博「点赞功能」数据库如何设计的》关于知识就介绍到这里，希望本站内容能让您有所收获，如有疑问可跟帖留言，值班小编第一时间回复。下一篇内容是有关《魅族手机解析包出错咋办？魅族玩王者荣耀有来电的时候会断线》，感兴趣的同学可以点击进去看看。

资源转载网络，如有侵权联系删除。