极客时间—架构实战营—第九期—模块二作业
一、朋友圈性能复杂度分析
首先,我们对朋友圈的功能进行拆分,可得到主要包括:“发朋友圈”, “看朋友圈”和 “朋友圈交互(点赞和评论)” 三个主要功能。
其次,我们确定系统的性能指标,通过搜索找到微信朋友圈在 2015 年的性能数据,数据引用自:https://mp.weixin.qq.com/s/O1jeKn4fDyrSj8opWFS4aQ (微信朋友圈技术之道:三个人的后台团队与每日十亿的发布量)。
性能指标如下:
在 2015 年 7 月,朋友圈日发表量 10 亿次,日浏览量 100 亿次,峰值时是平时流量的 5 倍;同时假设每个朋友圈状态平均有 10 次交互(点赞和评论),得以下性能复杂度分析图:
二、架构设计
我们按照模块二第五节的性能复杂度架构设计方法论,结合上述的分析,对朋友圈不同的功能进行高性能架构设计。
2.1、发朋友圈
架构设计如下:
设计理由:
单机面:计算高性能暂时不涉及无需考虑;存储高性能部分我们采用分库分表的 MySQL 集群来存储朋友圈数据(元数据),朋友圈本身内容采用 MongoDB 存储。
集群面:计算高性能采用负载均衡即可,发朋友圈无需再拆分;存储高性能则采用 MySQL 分库分表和 MongoDB 集群的方案
2.2、看朋友圈
架构设计如下:
设计理由:
单机面:计算高性能缓存模型部分,我们采用 Redis 集群来缓存热点朋友圈,应对“明星分手时”单个状态超大访问量的场景;存储高性能部分我们采用 Redis 集群+MongoDB 集群的两级存储方式。
集群面:计算高性能采用负载均衡,看朋友圈无法再拆分;存储高性能如上所示,采用 Redis 集群+MongoDB 集群的方案
2.3、朋友圈交互(点赞+评论)
架构设计如下:
设计理由:
单机面:计算高性能暂时不涉及无需考虑;存储高性能部分我们采用分库分表的 MySQL 集群来存储朋友圈互动记录,评论(互动)本身采用 MongoDB 存储。
集群面:计算高性能采用负载均衡即可,朋友圈互动不再拆分任务;存储高性能采用 MySQL 分库分表和 MongoDB 集群的方案
2.4、整体架构
综上所述,朋友圈的整体架构图如下所示:(ps:存在一个对称的机房做双活高可用)
三、总结
以上即为朋友圈的“发朋友圈”,“看朋友圈”和“朋友圈交互”三个功能架构设计方案。
相比于聊天和支付功能,朋友圈功能在微信中属于优先级不是那么高的功能点,极端情况下可以忍受一定程度的不及时、相应慢甚至一段时间内不可用,故其高可用性在此不做分析和设计。
版权声明: 本文为 InfoQ 作者【阿梁】的原创文章。
原文链接:【http://xie.infoq.cn/article/1cf55de868bea6b5a7112ffa1】。文章转载请联系作者。
评论