模块二作业

题干

对照模块 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 协议。