微博评论背后的高性能高可用计算架构

要求

分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容：

1. 计算性能预估（不需要考虑存储性能）；

2. 非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务；

3. 热点事件时的高可用计算架构

数据评估

发评论

微博本身是一个看多发少的业务，微博评论也是蕾丝，假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条，而考虑到更多的人会进行点赞操作，实际真正会去评论的人仅占部分（还有很多人的微博基本没有互动)，按照 2 倍计算，预估每天发评论 5 亿条

大部分的人写评论集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发微博总量占比为 60%，则这 4 个小时的平均发微博的 TPS 计算如下：

5 亿 * 60% / (4 * 3600) ≈ 20 K/s

看评论

由于大部分人都是看热点微博，很多发了的微博并不会被太多人可见，也不会点开看微博评论，假设没人每天读 100 条微博，其中 3/4 会查看评论

2.5 亿 * 100 * 0.75 = 187.5 亿

大部分人微博活跃时间基本重合，因此看评论的平均 QPS 计算如下：

187.5 亿 * 60% / (4*3600) ≈ 780K/s

架构设计

• 写评论和看评论，一个核心是读，一个核心是写，功能场景差异较大，需要考虑拆分为看服务和写服务，其中写服务重点是计算能力，读服务则更侧重缓存性能

• 同一时间段的热点事件往往比较聚焦，可能就是 top10 的热点，假如热点事件时读微博的性能扛得住，那对于评论而已，可以提供限流控制或写缓冲机制，降低评论的并发，提高系统处理效率，对于读评论则可以采用多副本机制

整体架构