用户量估算

看评论

1. 由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，查看评论为观看人数的 80%

2. 2.5 亿 * 80 = 200 亿

QPS：200 亿 * 60% /(4 * 3600) = 833 333= 850K/S(约)

写评论

1. 由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，写评论为观看人数的 60%

2. 2.5 亿 * 60 = 150 亿

TPS：150 亿 * 60% /(4 * 3600) = 650 000= 650K/S(约)

计算高性能高可用设计

看评论高性能

业务特性分析

看评论是一个典型的读操作，因此可用缓存架构，由于请求量很大，负载均衡架构也需要

架构分析

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

2. 请求量 200 亿，再加上一条微博的评论信息增加快，所以采用分布式缓存进行评论的缓存

架构设计

1. 负载均衡算法：用户查看评论，请求可以发送到任意服务器，可采用“轮询”、“随机”算法

2. 业务服务器估算：假设所有请求进入系统，则 QPS 为 850k/s ，由于读取评论处理逻辑比较简单，主要是读缓存系统，可假设业务服务器处理能力是 1000/s，则需要 850 台，按照 20%的预留量，最终机器数量为：1020 台

写评论高性能

业务特性分析

写评论是一个典型写场景，不需要数据缓存架构，由于请求量很大，需要负载均衡架构

架构分析

请求量 150 亿，应用多级负载均衡架构，DNS ->F5->ngnix->网关

架构设计

1. 写评论依赖用户登录状态，登录状态一般都是保存在分布式缓存中的，因此写评论的时候，可将请求发送到任意一到哪服务器，可选“轮询”、“随机”算法

2. 业务服务器数量估算：写评论关键步骤：内容审核、数据写入存储、数据写入缓存，因此一台服务器每秒处理 500 来估算，完成 650k/s 的 TPS，需要 130 台，加上 20%的预留量，总共需要 156 台服务器。

热点事件写评论高可用

业务特性分析

热点事件时，看评论和写评论都会落在某 1 条或者 2 条微博上，针对此类单条微博写评论请求会急剧增加

架构设计

1. 看评论，采用多副本缓存架构

2. 写评论，排队限流算法，评论先写到应用本地缓存队列中，独立线程从队列中获取评论进行数据落盘