写点什么

架构实战营模块 2 课后作业

用户头像
断水风春
关注
发布于: 刚刚

一、分析一下微信朋友圈的高性能复杂度

【作业要求】

1. 对照模块 2 讲述的复杂度分析方法,分析微信朋友圈的复杂度。

2. 针对各个复杂度,画出你的架构设计方案(无需做备选方案,只需要最终的方案即可)。

3. 给出你的架构方案中关键的设计理由。

4. 3~5 页 PPT 即可,涵盖复杂度分析、架构设计、设计理由。


【作业实现】微信朋友圈高性能复杂度架构分析和设计

(一)、微信朋友圈业务分析

材料分析:

2021 年 01 月 19 日,IT 之家 1 月 19 日消息 在微信公开课 Pro 直播演讲中,微信创始人张小龙披露微信最新数据:每天有 10.9 亿人打开微信,3.3 亿人进行视频通话,7.8 亿人进入朋友圈,1.2 亿人发朋友圈,朋友圈每天有 1 亿条视频内容,3.6 亿公众号,4 亿用户使用小程序。朋友圈每天有 1 亿条视频内容。每天有 3.6 亿人进入公众号,4 亿用户使用小程序


分析结论:

发朋友圈:每天 1.2 亿人发朋友圈,一天 86400 秒,平均每人每天发 2 条朋友圈,平均每秒有 2778 条动态。遇到国家大事或春节或除夕,人数提升 300%,发朋友圈数量提升 1.5 倍,按 3 条计算,最大瞬时峰值(TPS)为 12500 条朋友圈动态。


点赞:每秒有 12500 条朋友圈动态,按平均每人有 600 好友,假设 10%的好友会第一时间点赞,那么点赞瞬时峰值(TPS)为 75 万次。


浏览动态:每秒有 12500 条朋友圈动态,按平均每人有 600 好友,30%会看到你的动态,假设发朋友圈的人气很高,30%的朋友会第一时间同时浏览你的动态,那么浏览动态瞬时峰值(QPS)为 225 万次。


(二)、微信朋友圈高性能复杂度分析


(三)、朋友圈高性能复杂度应对思路

(四)、1-朋友圈发动态高性能方案


(四)、2-朋友圈发动态架构图

发动态架构说明:

1)、发朋友圈动态,计算高性上,采用 nginx 做任务分配,通过轮询/随机算法,负载均衡访问朋友圈应用服务器集群。

2)、存储高性能上,由于发动态内容有图片、视频等非文本格式,所以加了分布式文件系统做存储。

采用 Sharding-JDBC 地域范围分片,存储朋友圈动态文本、发布人、微信号、时间、可见人员等信息,到关系性数据库上,一般会采用 mysql 集群。


五、1-朋友圈点赞高性能方案

五、2-朋友圈点赞架构图

发动态架构说明:

1)、朋友圈点赞,计算高性上,采用 nginx 做任务分配,通过 hash 算法访问朋友圈应用服务器集群。

2)、存储高性能上,采用 spring-data 进行范围分析,访问 redis 集群,获取点赞人员列表缓存信息。

3)、点赞人员信息,并发性较高,所以采用 redis 缓存存储,再通过后台作业同步到 mysql 数据库集群中,以保证缓存与数据库一致。


六、1-朋友圈看动态架构图

看动态架构说明:

1)、看朋友圈动态架构,基本上等同发动态架构。

2)、区别于发动态架构,增加了缓存模型,首次访问关系数据库,获取朋友圈静态文本、发动态人员信息等,并到分布式文件存储系统(FastDfs),获取短视频、图片等信息。同时将数据库中的静态文本,缓存到 redis 带有效时间的缓存内,以便下次在有效时间内,看动态直接访问 redis 缓存。


七、朋友圈整体架构图

整体架构和选择理由:

1)、Nginx 做任务分配,朋友圈应用服务器多台集群

2)、朋友圈文本和发布者等信息,范围分片存储到朋友圈数据库集群;短视频、图片等存储到分布式文件系统;静态文本、点赞人员列表缓存到 RedisCluster 中。

3)、这种架构主要是从性能上考虑,对不同格式的数据做分流存储。

存储高性能,原先打算采用任务分解,对关系性数据库,进行读写分离,因为发朋友和看朋友圈访问频率差异很大,写少读多。但是考虑到成本等因素,读写分离未张罗进来。


用户头像

断水风春

关注

还未添加个人签名 2018.04.26 加入

还未添加个人简介

评论

发布
暂无评论
架构实战营模块2课后作业