架构训练营 -- 模块二

朋友圈业务主要包括：发朋友圈，看朋友圈，以及评论点赞

数据估算

根据新浪数据：https://www.sohu.com/a/445530372_114760，每天约有 7.8 亿人进入朋友圈，1.2 亿人发朋友圈，假设数据如下：

发送朋友圈

• 每人每天发 3 条朋友圈：1.2 亿*3 = 3.6 亿条朋友圈/天

• 二八原则估算 80%新朋友圈集中在每天的 20%的高峰时间段：3.6 亿*0.8 / 4.8 小时 约 1.7 万 TPS

• 瞬间 TPS 预估 5 倍约 8.5 万 TPS

看朋友圈

• 每天每天浏览 20 条朋友圈：7.8 亿*20 = 156 亿浏览/天

• 二八原则估算 80%浏览量集中在每天的 20%的高峰时间段：156 亿*0.8 / 4.8 小时 约 9 万 QPS

• 瞬间 TPS 预估 5 倍约 45 万 QPS

评论点赞

• 每天每天评论/点赞 10 条朋友圈：7.8 亿*10 = 78 亿浏览/天

• 二八原则估算 80%评论点赞集中在每天的 20%的高峰时间段：78 亿*0.8 / 4.8 小时 约 4.5 万 TPS

• 瞬间 TPS 预估 5 倍约 23 万 TPS

高性能复杂度分析

发朋友圈

• 发朋友圈主要是写操作，需要提升写性能，同时考虑朋友圈的展示是按用户按时间进行展示的，因此可以考虑基于 LSM 的 KV 存储模型提升写入性能，例如 HBase

• 通过负载均衡进行任务分配，发朋友圈本身业务模型简单，不涉及到任务分解

• 数据通过分片存储，由于发朋友圈本身是写数据，因此也不涉及读写分离等任务分解

看朋友圈

• 看朋友圈一般每天会产生多次请求，因此选择维护独立缓存提升读性能

• 通过负载均衡进行任务分配，看朋友圈本身业务模型简单，不涉及到任务分解

• 单机存储及集群存储与发朋友圈和评论/点赞重合，可以进行复用，因此不需要单独设计

评论点赞

• 整体复杂度与发朋友圈类似

• 评论点赞主要是写操作，需要提升写性能，同时考虑朋友圈的存储在 LSM 中基本也是按照时间倒叙存储的，因此可以考虑基于 LSM 的 KV 存储模型提升写入性能，例如 HBase

• 通过负载均衡进行任务分配，评论点赞本身业务模型简单，不涉及到任务分解

• 数据通过分片存储，由于评论点赞本身是写数据，因此也不涉及读写分离等任务分解

整体分析

• 主要数据存储于基于 LSM 的 Hbase 中，主要是考虑到发朋友圈和评论点赞的数据特征，具体包括：

• 数据以写入为主，需要提升写性能

• 朋友圈按时间排序，越旧的朋友圈访问量越低，同时点赞评论一般也是基于比较新的朋友圈，不会访问过于陈旧的 LSM Tree

• 由于 LSM 存储系统可能会读取多个 Tree，影响读取效率，可以通过 Redis 缓存数据，提升数据读取效率

• 缓存可以进行异步更新，将一定期间内 batch 的数据一起更新，也可以在用户主动刷新时进行更新，这个更新操作可以作为一个独立的服务在后台进行

• 最后还有一个考虑，微信是熟人社交，基本不会出现关注度很高的，类似微博大 V 这种用户，所以这种写时更新缓存的方案是可行的。但是思考如果出现类似微博明星用户这种，譬如某一个用户的关注者有 30M，这样的话在写时更新缓存的方案就会出现性能瓶颈，因为一个 Post 就会触发 30M 的 Cache 更新操作。这种情况下可以使用关系数据库然后通过 join 操作获取朋友圈，然后和缓存中的数据进行合并，相当于一种 hybrid 的方法