模块五

微博评论高性能高可用架构设计

一、性能评估

【看评论】

一般用户看微博都会附带看下评论，所以 QPS 近似等于看微博

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

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

【发评论】

假设用户看评论后，1%的概率会进行发评论操作，且发评论的时间段和看评论时间段基本重合

估算发评论的 TPS：1000K/s * 0.01 = 10K/s

二、是否需要拆分服务

1.考虑看评论的场景和看微博的场景结合紧密，一般用户看微博都会看下评论，所以看评论可以和看微博合并到同一服务

2.发评论与发微博的使用场景和频率也相对类似，可以合并到一个服务

三、架构设计

【看评论】

看评论是典型的读场景，一旦评论后不会再做修改，因此可以使用多级缓存架构，同时由于请求量大也需要使用多级负载均衡架构

【发评论】

发评论是典型的写场景，使用多级负载均衡架构

由于用户量上亿，需要覆盖 DNS->F5->Nginx->网关的四层负载

四、热点事件下的计算高可用设计

【看评论】

主要容易在大 V 的微博中发生热点评论，可以采用多副本缓存，通过应用缓存已大幅降低了热点问题

【发评论】

发评论的业务重要性和实时性要求相对发微博来说要低一些，因此可以采用漏桶算法进行写缓冲

在服务压力大的情况下可以进行限流和降级的策略，限制用户评论的操作