架构训练营 模块二作业

微信朋友圈高性能复杂度

根据网上获得的信息：

截止到 2015 年 7 月，微信每月活跃用户约 5.49 亿，朋友圈每天的发表量（包括赞和评论）超过 10 亿，浏览量超过 100 亿。得益于 4G 网络的发展，以上数据仍有很快的增长，而且相对于 PC 互联网时代，移动互联网时代的峰值要来得更加凶猛。比如，2015 年元月的流量到了平时的 2 倍，而峰值则达到了平时峰值的 2 倍，相当于平时正常流量的 5 倍。

如果以此作为参照依据，我们可以提取出以下信息：

微信的主要业务有：

1. 动态发表

2. 点赞

3. 评论

4. 浏览动态和评论

相应的数据：

1. 月活用户是 5.49 亿

2. 每天发表量（动态、点赞、评论）超过 10 亿

3. 每天浏览量超过 100 亿

4. 而高峰值是正常流量的 2.5（因为元月的峰值是平常峰值的 2 倍，正常流量的 5 倍）倍

我们假设一条动态下，点赞平均有 10 个点赞，5 条评论。

• 那么每天的动态发表量大约为：10 亿/16 = 6250 万

• 每天点赞数大约为：6.2 亿

• 每天的评论数大约为：3.1 亿

• 每天的浏览量为：100 亿

假设这些的发生都集中在 8 点~22 点这个区间内，则 TPS 和 QPS 为：

• 动态发布：1240/秒（TPS）

• 点赞数：11240/秒（TPS）

• 评论数：6200/秒 （TPS）

• 浏览量：20 万/秒 （QPS）

而元月等高峰期的量级会是 5 倍，也就是：

动态发布量：6200/秒 （TPS）

点赞数：56200/秒 （TPS）

评论数：31000/秒 （TPS）

浏览量：100 万/秒（QPS）

如此看来，微信的业务复杂度并不高，但是质量复杂度较高

微信朋友圈高性能方案--动态发布

微信朋友圈高性能方案--点赞评论

微信朋友圈高性能方案--看朋友圈

整体架构

如此架构的理由：

1. 因为朋友圈的动态主要由三部分组成：动态文本、动态图片/视频、评论点赞

2. 动态文本和评论点赞可以存储在关系型数据库里，而我在自己微信朋友圈里可以查看 2013 年的信息，显然这个数据不止是缓存，而是持久化的。从成本考虑，mysql 比较适合存储这样的信息。

3. 而图片和视频则比较适合存储在 OSS 服务器上，用一定的规则与动态关联（例如动态 ID），在加载朋友圈动态的时候，可以分别从关系型数据库和 OSS 数据库同时获取数据，这样也可以降低每种服务器的负载，同时提升读取性能。OSS 数据库可以根据动态的 ID 的 hash 值来分配到不同的 OSS 服务器上，从而实现视频和图片的分片存储。而 OSS 服务器在容量不够的情况下，也可以进行扩容和增加服务器

4. 高峰期每秒 100 万的读取量，直接打到数据库上的话，数据库是吃不消的，因此需要用缓存来帮助分担这部分的流量。对于经常被看的动态，完全可以用 redis 缓存下来，图片和视频依然从 OSS 服务器获取。而一段时间不看的动态可以从缓存清理，减少缓存的使用容量（不可能把所有的动态都缓存下来，太占空间了）

5. 数据库最好可以实现主从备份，而三机房也同样是一个异地多活的方案：防止某机房的网络出现问题，另外两个机房可以顶住如此大的流量。