写点什么

架构实战营模块二作业

用户头像
刁寿钧
关注
发布于: 2021 年 04 月 23 日

模块二作业

题干

对照模块 2 讲述的复杂度分析方法,分析微信朋友圈的复杂度;针对各个复杂度,画出你的架构设计方案(无需做备选方案,只需要最终的方案即可);给出你的架构方案中关键的设计理由。3~5 页 PPT 即可,涵盖复杂度分析、架构设计、设计理由。

题解

业务特点分析

朋友圈的业务复杂度及特点:


  • 用户量:2020 年底,微信 MAU 为 12.25 亿(2021Q1 财报数据)。按DAU/MAU=95%的经验估算,DAU 约 11.6 亿。

  • 每天活跃量:写业务(发表+赞+评论)按DAU*2估算,约 20 亿。读业务(浏览)按读写比 100:1 估算,约 2000 亿;即每分钟访问约 5000W 量级。

  • 节日效应:节假日狂欢(元旦、除夕、情人节、圣诞、520 等)。按经验节日流量:平时流量约为 2:1。

  • 突发效应:节日的零点、重大比赛、热点事件,都会引发突发峰值。突发峰值:平时峰值可按 5:1 估算。

  • 冷热分明:1 天内的数据访问占 70%,1 月内的数据访问占 90%;半年外的数据访问占 3%,一年外的数据访问占 1%。

架构方案与说明



  • 图片和视频的上传、存储、分发走 CDN。底层使用自研的 KV 存储,可以认为是 NoSQL。


  • 节日效应。

一般而言,当模块容量不足时,扩容是常规的思路。这里可以分享一个思路。朋友圈存储所用的 key 都带有时间属性,即朋友圈数据在时间维度上是有序的。节日期间的访问增量,都是新增的活跃数据带来的。所以可以为这些活跃数据搭建一个临时的存储服务集群。

客户端根据访问 key 所带的时间范围决定转发到哪个集群。效果类似于扩容,但不涉及旧数据的迁移。

临时服务的数据量少,而计算压力大,可采用 CPU 性能较高的机型。

到了节后,可以设定一个时间节点,此节点后,临时服务只有数据访问,而无新 key 的生成,后续的数据回流迁移也很可控。


  • 冷热分明。

冷数据访问量明显低于热数据,可搭建冷数据集群模块,存储部分冷数据,并承担相应访问,以降低单位存储成本。


  • 缓存策略。

朋友圈业务中,存储数据读写比可以达到 100:1。所以可以使用写时不更新、读时更新的策略。

在存储层和缓存层的数据都维持一套版本号。存储层的 version 随着数据的更新的单调增长,缓存层的 version 单纯向存储层看齐。只交流版本号,不需要传输数据,在读多写少的情况下,可以极大降低网络流量。

对于存储层,因为版本号请求场景,要支持很高的 TPS。要保证所有的版本号都在内存中,访问无需落盘。

这里有个问题要注意,如果数据大小差别比较大,而混在同一份缓存中,会造成大数据挤压小数据。小数据本来只需要很少的内存就可以达到高命中率,却会不断被大数据抢夺内存空间。存储层数据平均大小按 1k 估算,版本号是定长数据,一般也就十几字节;所以版本号与普通数据要独立缓存。


  • 请求合并与路由收敛。

存储层达到较高的缓存命中率后,更多的消耗主要在网络交互阶段。朋友圈多个 Get 请求可以经批处理聚合成一个 BatchGet 请求。

另外,BatchGet 请求中的 key 在用户维度具有相关性,但落到存储层时,会经哈希后路由到不同的存储机器上。因此还要做一件事,就是路由收敛,将落在同一台机器上的 key 请求聚合起来。


  • 写业务。

在存储缓存层,数据(发表、评论、赞)单副本,减少存储开销。数据都是有全局唯一 key 的。

相册与发表数据,本地 IDC 写入,单向同步到其它 IDC。全局唯一 key 无冲突。

评论/赞数据,本地 IDC 写入,双向同步到其它 IDC。这里会遇到写冲突,保证 key 因果一致性。

时间线数据,本地 IDC 只需保存本地用户时间线的 key,无需同步。


  • 容灾。

存储层三机一组,容忍一台出错、自动切换。

三机分布在三个独立园区,容忍一个园区网络隔离。


  • 延迟。

跨国访问拉专线。专线中断时自动切换到公网,注意加密保障。

延迟、丢包、乱序达到一定程度时,从 TCP 切换到 UDP 协议。

发布于: 2021 年 04 月 23 日阅读数: 18
用户头像

刁寿钧

关注

还未添加个人签名 2018.03.13 加入

还未添加个人简介

评论

发布
暂无评论
架构实战营模块二作业