模块五（微博评论）

计算性能预估

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台服务器差不多了

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

多级负载均衡架构

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

【业务特性分析】

热点事件时，评论大多写在热点微博下，刚写的评论可能就会被后面的人刷到后面，看不到了，所以它的重要性及响应力是比较小的，但也要保证尽量不要丢评论，

所以可以考虑进行限流，采用漏斗算法

。非热点时写缓存的大小是10到12万,此时可以将它扩大10倍，到100万或120万。

限流的方法：

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

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