模块二作业：微信朋友圈复杂度分析

复杂度分析

• 背景：根据微信官方数据，朋友圈的访问人数为 7.8 亿，发表朋友圈人数为 1.2 亿，其中照片 6.7 亿张，短视频 1 亿条。

• 峰值请求分析（不考虑元旦、春节等特殊节日）

• 发朋友圈：每天发朋友圈人数为 1.2 亿，假设每人每天发 1.5 条朋友圈，70%的朋友圈发在 16:00 - 24:00，发朋友圈的 TPS 可以计算为 1.2 亿 × 1.5 × 70% ÷ (8h × 3600s) = 4375

• 计算高性能

1. 进程模型：C++多进程处理图片、短视频等多媒体数据（压缩、转码等）。

2. 网络模型：不考虑

3. 缓存模型：不考虑

• 存储高性能

1. 多媒体数据通过对象存储进行存储，并通过 CDN 进行加速。

2. 朋友圈其他数据通过 MySQL 集群进行存储

• 看朋友圈：每天访问人数 7.8 亿，假设每人每天看 3 次朋友圈，70%的访问集中在三个时间段（上班路上（8:00 - 10:00），午休前后（11:00 - 14:00），下班后（18:00 - 23:00）），访问朋友圈的峰值 QPS 可以粗略计算为 7.8 亿 × 3 × 70% ÷ (10h × 3600s) = 45500。

• 计算高性能：不考虑

• 存储高性能

• Redis 中缓存最近 3 天的朋友圈数据，访问最近 3 天的数据时优先访问 Redis 集群，3 天后数据访问 MySQL。

• 用户间交互：朋友圈用户的交互主要为点赞和评论，假设平均每条朋友圈获得 10 个点赞和 2 条评论，点赞的 TPS 为 45500 × 10 = 455000，评论的 TPS 为 45500 × 2 = 91000

• 计算高性能：不考虑

• 存储高性能

• 点赞数据通过 Redis 集群，利用 Set 数据结构进行存储。

架构设计

单机房：

多机房：分区存储，DNS 负载均衡，就近访问

设计理由

1. 计算高性能：业务逻辑上利用微信原有架构，针对朋友圈的大量图片以及视频数据，增加针对图片和短视频数据处理的服务。

2. 存储高性能

3. 朋友圈存在访问控制、朋友关系的存储需求，利用关系型数据库（MySQL）集群方便上述场景；

4. 点赞功能对性能要求高，但是质量复杂度低（允许丢数据），每条朋友圈每个人只能点赞一次，因此选用 Redis 的集合数据结构进行存储。

5. 大部分人看朋友圈时只看近期的动态，且很多人设置朋友圈为“仅三天可见”，考虑到朋友圈的访问 QPS 较高，通过 Redis 缓存近 3 天的数据，提高访问效率，如果存在访问未命中或 3 天外的数据再访问 MySQL。

6. 图像、视频数据对存储资源的占用较高，一般用文件系统进行存储，此处选用 OSS 存储图像和视频数据，在 MySQL 中只存储数据的 URI，并通过 CDN 进行加速，提高访问性能。

7. 根据微信的访问量级，采用多机房、就近访问，通过 DNS 做负载均衡，提升访问性能。