模块五：微博评论的高性能高可用框架

1. 计算性能预估

“微博评论”（包括发评论和看评论）与“看微博”是密切相关的。“微博评论”一般是发生在“看微博”后的一段较短时间内发生的。

假设平均看微博的人中有 20%的人会发评论、90%的人会看评论。参照《第 6 课》中，“看微博”的预估（即：每日发布 250 亿条、TPS 为 1000k/s），则可预估“发评论”和“看评论”的性能：

• 发评论：每日发布 50 亿，TPS 为 200k/s

• 看评论：每日看评论次数 225 亿，TPS 为 900k/s

2. 非热点时的高性能计算架构

• 看评论：根据对“看评论”的性能预估，它和“看微博”的性能预估相差不多，可以采用和“看微博”相似的架构，但由于“看评论”不算核心业务，允许降低一定的性能，参照《第 4 课》的多节负载均衡架构，选择去掉 F5/LVS 后的 3 级负载均衡架构，服务器集群选择 100 台。

• 发评论：根据对“发评论”的性能预估，与“发微博”相比，每日发布的数量和 TPS 均为后者的 10 倍，但考虑“发评论”实时性没有那么高，且发送内容较少，故选择去掉 F5/LVS 后的 3 级负载均衡架构，其中，负载均衡算法选择“轮询”或者“随机”算法、使用 kafka 作为消息中间件缓冲写数据、考虑将“发评论”拆分出单独的服务并单独部署（主要是因为“发评论”的时效性要求不高并且不是核心的业务流程），服务器集群选择 20 台服务器。

3. 热点事件时的高性能计算架构

• 看评论：和“看微博”的应对措施一样，需要设计多副本缓存来应对热点。

• 发评论：发评论的时效性和重要性要低于“发微博”，可以考虑对“发评论”进行限流，采用漏桶算法的变种-写缓冲来实现。