模块 5 作业

用户量：

2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）

需要评估的行为：

评论微博

考虑到人们喜欢评论他人消息，假设平均每人每天评论 6 条微博，则微博发送量为 15 亿条。

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

业务特性分析：

这是个典型的写操作，可以用 kafka+负载均衡。

架构分析：

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡，+kafka

架构设计：

1， 负载均衡算法

评论微博的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此评论微博的时候，将请求发送给任意服务器都可以， 这里选择“轮询”或者“随机”算法，对于大 V 的评论，转发到一台单独的大 V 服务器上。

2， 业务服务器数量估算

这里只有异步写的操作，可以按照每秒 1000 来估算。完成 60k/s TPS,需要 60 台服务器。

这里可以采用发微博的多节负载均衡架构。把服务集群改为 60 台服务器就好了。

这个场景很简单，不需要独立的服务集群。可以和发微博公用。

但是需要另外一个可伸缩的集群消费 kafka 消息就好了。

热点微博的高可用分析：

热点事件指某个大 V 或者明星爆料或者官宣，虽然只有一两条微博，但引起大量用户在短时间内访问，给系统 造成很大压力。这时候可能在 1 小时内有上百万的评论。

架构设计分析

评论

1， 负载均衡算法

因此评论微博的时候，将大 v 请求发送给大 V 服务器， 这里选择权重算法

评论分为大 v 评论和一般的评论。

对大 V 的评论不做限流，对一般的人的评论可以做出限流处理。可以用漏铜算法。

在 kafka 中可以有专门的大 V topic 优先消费，或者加一台大 V 服务器，对大 V 评论采取同步写入操作。其他的评论异步处理。