计算性能预估

2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》），参考老师之前对于发微博的分析，微博每天的发送量为 2.5 亿条,TPS=10k/s。微博评论主要集中于大 V 或明星，因此假设一天微博对应 10 条评论，则评论的次数为：2.5 亿*10 = 25 亿，大部分评论的时间段与发微博重合，则它的 TPS=10*10 = 100k/s.

非热点事件的高性能架构

分析

【业务特性分析】

这是一个写操作，但是写完后并不需要立即展示 ，它的时效性不如发微博，同时写完后，可以认为它是不会修改的，并且要保证不要丢掉，比较适合用缓存，异步处理 同时因为一天评论次数很多，需要用负载均衡

【架构分析】

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。 采用 kafka 集群做写缓存，写评论进行缓存，先进先出，异步处理，TPS 为 10 万/s, 所以缓冲队列的容量也可以设置为 10 万到 12 万

【架构设计】

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

2. 业务服务器数量估算 写评论及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因 此按照一个服务每秒处理 500 来估算，完成 100K/s 的 TPS，需要 200 台服务器，加上一定的预留量，250 台服务器差不多了

3. 写评论的时间段虽然大部分情况下与发微博是相同的，但有时也并不重叠，有时可能是微博发出好几个小时，甚至是几天后才写评论。一条微博，可能有上万人阅读，一，二千人评论，发评论的次数与发微博，看微博的次数是相差比较大的，所以需要将评论设置为单独服务

多级负载均衡架构

评论多级负载均衡架构

热点事件时的高可用计算架构

【业务特性分析】

热点事件时，评论大多写在热点微博下，刚写的评论可能就会被后面的人刷到后面，看不到了，所以它的重要性及响应力是比较小的，但也要保证尽量不要丢评论，所以可以考虑进行限流，采用漏斗算法。非热点时写缓存的大小是 10 到 12 万,此时可以将它扩大 10 倍，到 100 万或 120 万。

限流的方法：

• 发生热点事件，且判断可能会影响系统可用性时，可通过人工，下达指流指令，限制接收用户评论的接口。

• 在 kafka 写评论缓存队列时，如果缓存满了，可丢掉后续的写操作