微博评论系统高性能高可用计算架构 - 模块 5

1.微博评论场景的用户行为建模和性能评估

参照性能评估方法对业务场景进行性能评估：

发微博

考虑到微博是一个看得多发的少的业务，假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条。

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

看微博

由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，则观看微博的次数为：2.5 亿 * 100 = 250 亿。

大部分人看微博的时间段和发微博的时间段基本重合，因此看微博的平均 QPS 计算如下：250 亿 * 60% / (4*3600) = 1000K/s。

微博评论

假设每条发出去的微博都能收到 5 条评论，基于发微博的 TPS 换算评论微博场景的 TPS 为： 10K/S*5 = 50K/S

2.微博评论场景的高性能架构设计

业务特性：微博评论场景也是典型的写操作，但是实时性要求没有发微博场景高，热点事件场景评论较多，评论易被快速淹没，用户一般 对实时性要求没那么高，但是写好的评论数据不可丢弃

架构分析：

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

2. 考虑到微博评论场景实时性要求不高，因此考虑引入 kafka 这类消息队列作为写缓冲，做异步缓写架构，同时也可以应对热点事件突发流量，对请求进行削峰填谷

架构设计：

1.负载均衡架构中算法选择

评论请求同样无状态，无需 ip hash 到固定服务器，可以发到任意服务器，因此可以采用“轮询”或“随机”算法即可

2.业务服务器数量估算

评论微博同发微博，涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 50K/s 的 TPS，需要 20*5=100 台服务器，考虑到核心业务都是异步缓写，因此预留量不用太多，给 20 台。

整体架构图：

评论子系统架构示意图

评论子系统需要做任务分解，将评论服务和评论作业服务集群分离，评论服务只是接收请求，快速写入 kafka 队列，不做内容审查等业务，耗时的业务都放在作业服务中去异步处理。

对于热点事件场景的处理策略

1. 业务降级，比如热点事件发生时，尽量保证看微博，转发微博服务，降级发微博，以及评论服务，以保障主业务场景的可用性。可以将评论作业服务集群资源重新分配到看微博服务，转发微博服务，以及评论服务集群保障，评论数据全部写入 kafka 数据，保证不丢。评论作业服务集群甚至可关闭。

2. 业务限流，所有服务器都已倾斜到核心服务后，仍然无法抗住流量时，可进行漏桶限流，丢弃部分看微博请求