架构实战营 - 模块 02 作业

晖

关注

发布于: 2021 年 04 月 18 日

作业要求

对照本模块当中的复杂度分析方法，分析微信朋友圈的高性能复杂度。
针对各个复杂度，画出架构设计方案。
给出架构设计方案中关键的设计理由。

数据采集与复杂度分析

数据以 2021 年 1 月微信公开课 Pro 的直播视频演讲中的为基准。
每天有 7.8 亿人进入朋友圈。
每天有 1.2 亿人发朋友圈。
朋友圈每天有 1 亿条视频内容。
资料没有披露看朋友圈总量，根据上述信息估算为每天 100 亿条次阅读（读取）。
进入朋友圈的假设刷 100+ 条朋友圈。
100+ 条朋友圈约分 10 次进行读取。
资料没有披露发朋友圈总量，根据上述信息估算为每天 5 亿条发送（写入）。
对比微博、Twitter，朋友圈不是公开社交。
因为这个特性，不会出现某名人发一条朋友圈引起流量洪峰。
朋友圈在一天当中的流量分布应该较为均匀。
微信有很多海外用户，但大多数用户依然集中在中国。
假设一天中有 85% 的请求发生在 50% 的时间中。
既海外用户占总用户的 15%，国内用户在一天的 12 小时中均匀玩朋友圈。
那么可以得出读取约为： (85% x 100 亿) / (50% x 24 hr x 3600 sec) = 2,00,000 (二十万) QPS.
同理可以得出写入约为： (85% x 5 亿) / (50% x 24 hr x 3600 sec) = 10,000 (一万) TPS.

朋友圈发布、点赞、评论应对思路

高效的编程语言。
消息队列减小数据库压力。
数据库对一致性要求不高，读时高可用、高性能要求很高。保证最终一致性即可。

朋友圈阅读应对思路

高效的编程语言。
读多写少，使用只读缓存大幅提高读性能。
数据库对一致性要求不高，读时高可用、高性能要求很高。保证最终一致性即可。

整体架构设计理由（包含上述发布、点赞、评论 + 阅读）

朋友圈访问人数多：
通过 DNS 分配到不同区域集群，全国多机房部署。
服务器集群在保证高可用的同时，保证每个单机有足够的性能来处理请求。
使用分布式数据库。
采用以上设计以保证高性能。
朋友圈业务：
正文、点赞、评论、阅读均相对独立。
每个子业务 TPS/QPS 差异大。
通过业务拆分以保证高性能和高可用。
读多写少，采用读写分离架构：
写链路（Write Path）中：
图片、视频直接分发至文件存储系。
消息队列 Kafka 保证写入高性能要求。
统消费者集群处理 Kafka 中的消息。
虽然业务读多写少，但两者流量都不低。
读链路（Read Path）中：
Redis Cluster 只读缓存，保证正文、点赞、评论的读取高性能要求。
CDN + DNS 鉴权，保证图片、视频的读取高性能要求。
朋友圈数据：
修改和删除较少。
新增（正文）和添加（点赞、评论）较多。
不用永远显示最新数据，只要数据最终某个时刻能被用户看到即可，既最终一致性。
数据库可以选择 AP 型数据库，保证 Availability 可用性，而损失一些 Consistency 一致性。
采用 Cassandra 数据库:
由 Facebook 开发，典型的 AP 型数据库，在社交业务中被大量验证。
把一个朋友圈作为一个宽行（Wide Column）存入，每次有新增就在此行增加信息。
降低数据库层复杂度的同时保证了原子性。
Cassandra 的读取速度也出了名的快，和 Redis Cluster 层相辅相成。
天然满足多区域、多机房部署的要求。