用户量

2020.9 月 月活 5.11 亿，日活 2.24 亿。

关键行为

微博评论系统分发评论和看评论两个功能，与案例的发微博和看微博功能类似。

用户行为建模和性能评估

发评论

发评论和发微博类似，是一个看得多，发得少的业务，假设每天发送的微博条数为 2.5 亿，每条微博平均能收到 5 条评论，则每天发送的评论数为 12.5 亿条。

大部分人发评论和发微博的时间段相同，按照高峰时段 8-9，12-13，20-22 发送 60%的评论数估算，发评论的 TPS=12.5 亿*60%/4=50k。

看评论

看评论和看微博的 QPS 大致相同，估算为 1000k。

微博高性能计算架构设计

发评论

发评论是一个典型的写操作，用户量过亿，架构需要用多级负载均衡架构，同时请求依赖登陆状态，登陆状态往往使用分布式缓存，因此请求可以发送到任意服务器，因此负载均衡可以用轮询或者随机算法。

但是和发微博的实时性要求比较高不同，发评论后用户往往并不会去查看自己的评论，实时性要求不高，所以可以用缓冲队列来接收发评论请求。

服务容量估算：发评论涉及几个关键的处理和发微博相同:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)，参照发微博按照一个服务 TPS 为 500 来估算，完成 50k 的请求需要 100 台服务器，考虑到一定容量的预留，我们一共需要 120 台服务器。

发评论的多级负载架构

发评论的缓冲队列架构

看评论

看评论和看微博类似，是一个典型的读多写少的场景，因此适合使用多级缓存架构。其中 CDN 是关键和缓存技术。

同时由于请求量大，因此也需要多级负载均衡架构。看评论也是一个无状态的请求，因为负载均衡可以使用随机或者轮询的算法。

服务容量估算：看评论按看微博的 QPS 1000k 估算，假设 CDN 承载 90%的流量，服务器承载 10%的流量，服务器的 QPS=10k，由于看评论主要依赖缓存系统，服务器计算压力不高，假设单服务器可以处理的 QPS 为 1000，那么估算需要 100 台服务器，考虑到一定容量的预留，需要 120 台服务器。

读评论的多级负载架构

读评论的多级缓存架构