架构训练营模块 2 作业 - 听闻

分析

张小龙透露: 微信的日活跃用户达到 10.9 亿；有 7.8 亿人每天翻看着朋友圈，其中的 1.2 亿人还会在朋友圈里发点什么.

一般情况下高峰时期为平均的 3 倍左右, 遇到热点话题, 比如著名的比赛夺冠了, 重要人物去世, 新年快乐等, 可能一段时间的流量要再翻 3 倍, 所以可热点时流量可大致认为是平均的 9 倍, 架构设计上, 针对热点峰值, 再*2.

假设 7.8 亿人看朋友圈, 假设平均每人刷 20 次朋友圈,

浏览量 QPS: 7.8 亿 x 20 /86400 x 18= 324 万/s

假设每 5 次浏览, 进行一次点赞/评论.

评论点赞 TPS: 162 万/5=64 万/s.

假设 1.2 亿人每人每天发 2 条朋友圈

发表 TPS: 1.2 亿 x 2 / 86400 x 18= 5 万/s

朋友圈写架构

因为微信的用户的归属是按照 idc 进行划分的. 用户的数据数据在用户所在的 idc.

1. 所以首先朋友圈在整体上也是有多个 idc 的.

2. 其次朋友圈请求量和数据量极大, 不管是逻辑层还是存储层, 都是需要非常多的机器来进行负载均衡的.

3. 因为朋友圈的数据极大, 且在不断的快速增长中, 数据的划分, 这里需要有一层数据 proxy 层, 方便存储层的扩容.

4. 同时朋友圈数据为 table store 模型, 微信自研了 paxos kv, 多台机器为一组进行存储, 一个存储层有非常多组存储. 如果自己开发的话, 可以使用 mysql 分库分表来进行存储. 同时需要做 mysql 的主从半同步.

5. 因为不同 idc 之间的用户可能有好友关系, 所以还涉及到 idc 之间的数据同步. 所以不同 idc 之间还需要有跨城队列.

朋友圈浏览读架构

因为朋友圈有的数据有比较强的时间属性, 对于当天的数据浏览最多, 对于之前的数据, 浏览则会少很多.

可以在数据 proxy 层和存储集群之间, 搭建热点集群来缓存最近几天的数据. 图就不画了.

逻辑层分服务

因为读写差异很大, 所以逻辑层可以分为不同的服务, 使用不同的路由和 rpc 方法. 比如可以分成

1. 发朋友圈模块, 数据扩散模块.

2. 浏览朋友圈模块

3. 点赞模块

4. 评论模块