讨论个问题！微信朋友圈的数据库是怎么设计的？

首先可以肯定的是，微信有N个数据库；不同的业务甚至说小功能的数据库应该都是不同的。而且我同时可以肯定，微信不会用数据库直接聚合查询来做数据统计。

坐等标准答案

可以参考下微博的数据库设计

朋友遇到一个面试题，微信朋友圈怎么设计？

图片有、东西

想知道 learnKu 数据库怎么设计的

本来就在床头，为什么又藏在床头了。。。 :flushed:

细致划分：系统与子系统、模块与组件、框架与架构
微信本身是一个系统，包含聊天、登录、支付、朋友圈等子系统。
朋友圈这个系统又包括动态、评论、点赞等子系统。
评论这个系统可能又包括防刷子系统、审核子系统、发布子系统、存储子系统。
评论审核子系统不再包含业务意义上的子系统，而是包括各个模块或者组件
这些模块或者组件本身也是另外一个维度上的系统。例如，MySQL、Redis 等是存储系统
数据库设计又分为一主一从、一主多从、多主多从，机房可以是同城双活、异地多活

如果按照我自己的常规做法来说，就是使用mysql对用户进行log纪录。

然后使用ES等类似NoSQL数据库实现数据同步，然后在查询时使用 terms 进行过滤，这样就可以查询相关记录了。

然后在获取相关评论的时候，同时对你的好友进行过滤。

然后中间在插入一些广告，当然这应该是另外一个服务实现的，估计就是调用个接口的事情。

这里没考虑到的是量级的问题。问我我也回答不出，因为我没有腾讯这么大的量级。

还有什么没考虑到的可以互相沟通。

• 咳，要我去面试我会直接说不知道。确实没设计过用户量几个亿的系统。而且还仅是用户量。朋友圈数量根本是另一个数量级，马克斯告诉我们，量变会引起质变。我们设计的东西与人家在用的根本就不是一码事。
• 所谓夏虫不可语冰，我跟做毕业设计的小伙伴讲分库分表数据库中间件微服务群集的时候他也一脸不可置信，认为这完全没必要。这还仅仅是分库分表，何况朋友圈呢。
• 微信消息，朋友圈并不存储在腾讯的服务器上，至少腾讯是这么说的，那么简单了，腾讯只需要存储一小部分没被终端（手机）取回去的滞留消息和滞留朋友圈就好了。数据量可能并没有我们想象的那么大，如果腾讯是诚实的话，as we all know 。腾讯说这话的时候其实一直在眨眼的。

我是这么设计的，朋友圈可以理解为“feed流”，“时间轴”。短视频、公众号文章、分享来的链接、图文等等，都是一个单独的对象，有自己独自的表结构，单独建立表，例如moment_video、moment_image，用来记录每种单独的数据结构，然后再建立一个moment表,用来记录统一的信息，比如发布者ID等。 这是很常见的问题了，可以根据信息流表结构设计这个关键词去Google，by the way，laravel的多态很适合这种需求，后续数据量大的话可以再做个mongo来动静分离

好问题，我觉得都能单独写一篇文章了。但是面试问这个是不是有点大病 :unamused:

附上一个QQ架构案例分析： 手机 QQ 的发展历程按照用户规模可以粗略划分为 4 个阶段：十万级、百万级、千万级、亿级，不同的用户规模，IM 后台的架构也不同，而且基本上都是用户规模先上去，然后产生各种问题，倒逼技术架构升级。

1. 十万级 IM 1.X 最开始的手机 QQ 后台是这样的，可以说是简单得不能再简单、普通得不能再普通的一个架构了，因为当时业务刚开始，架构设计遵循的是“合适原则”和“简单原则”。

2. 百万级 IM 2.X 随着业务发展到 2001 年，QQ 同时在线人数也突破了一百万。第一代架构很简单，明显不可能支撑百万级的用户规模，主要的问题有： 以接入服务器的内存为例，单个在线用户的存储量约为 2KB，索引和在线状态为 50 字节，好友表 400 个好友 × 5 字节 / 好友 = 2000 字节，大致来说，2GB 内存只能支持一百万在线用户。 CPU/ 网卡包量和流量 / 交换机流量等瓶颈。 单台服务器支撑不下所有在线用户 / 注册用户。 IM 2.X 的最终架构如图

3. 千万级 IM 3.X 业务发展到 2005 年，QQ 同时在线人数突破了一千万。第二代架构支撑百万级用户是没问题的，但支撑千万级用户又会产生新问题，表现有： 同步流量太大，状态同步服务器遇到单机瓶颈。 所有在线用户的在线状态信息量太大，单台接入服务器存不下，如果在线数进一步增加，甚至单台状态同步服务器也存不下。 单台状态同步服务器支撑不下所有在线用户。 单台接入服务器支撑不下所有在线用户的在线状态信息。 M 3.X 的最终架构如图

4. 亿级 IM 4.X 业务发展到 2010 年 3 月，QQ 同时在线人数过亿。第三代架构此时也不适应了，主要问题有： 灵活性很差，比如“昵称”长度增加一半，需要两个月；增加“故乡”字段，需要两个月；最大好友数从 500 变成 1000，需要三个月。 无法支撑某些关键功能，比如好友数上万、隐私权限控制、PC QQ 与手机 QQ 不可互踢、微信与 QQ 互通、异地容灾。 除了不适应，还有一个更严重的问题： IM 后台从 1.0 到 3.5 都是在原来基础上做改造升级的，但是持续打补丁已经难以支撑亿级在线，IM 后台 4.0 必须从头开始，重新设计实现！ 架构拆分为两个主要的架构：存储架构和通信架构，重新设计的 IM 4.0 架构如图 存储架构：

通信架构：

参考文献：《QQ 1.4 亿在线背后的故事》

相关的技术架构截图，请参考