题目

答案

业务分析

性能估算

根据发微博和看微博的业务评估，假设每条被看的微博有 10%的概率被评论，即评论微博数为看微博数的 10%，则评论微博的次数为：2.5 亿 * 10 = 25 亿。

评论微博和看微博的时间使重合的，因此评论微博的 TPS 计算如下：

25 亿 * 60% / (4*3600) = 100K/s。

业务特性分析

评论微博虽然是一个写操作，但是与发微博比起来实时性要求没那么高，因此可以使用写缓存和负载均衡。评论微博与发微博和看微博的业务关联性不大，需要独立服务。

高性能架构

架构分析

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

架构设计

1. 负载均衡算法选择

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

2. 业务服务器数量估算

评论微博涉及几个关键的处理：内容审核（依赖审核系统）、数据写入缓存（依赖缓存系统），因为评论微博对实时性要求不高因此这里采用写缓存的方案，评论数据写入缓存之后就直接返回给用户，再异步将缓存中的评论数据写入到数据库。按照一个服务每秒处理 800 来估算，完成 100K/s 的 TPS，需要 125 台服务器，增加 25 台预留量，共 150 台。

高可用架构

热点事件分析

当有热点事件发生时，评论微博主要分布在热点微博和转发的热点微博，但是绝大部分的微博评论会落在原创的热点微博上。

高可用架构分析

评论的实时性要求不高，评论完之后也未必可以立即刷到自己评论的数据。但是考虑评论时的用户体验，需要尽量少的丢弃请求，因此可以考虑先写缓存的基础上加上限流，限流采用“漏桶算法”。

架构设计