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

性能估算

1：基于课程中看微博的假设，每日看微博的量是 250 亿，看微博的 qps 为 1000K/s。

2：假设平均看 100 次微博会发布一次评论。

3：评论微博和看微博热点时间段均相同。

基于以上 3 个条件，可以推断出评论微博每日的量是 2.5 亿，评论微博的 tps 为 10K/s。

业务特性分析

微博评论是一个典型的写操作，因此不能用缓存，可以用负载均衡，并且存在针对某一微博短时大量写请求的情况，但微博评论一般都是评论完没有自己二次查看的请求，一般由其他看评论的人查看，因此可以通过写入缓冲慢慢处理，可以忍受短暂的延迟处理。

架构分析

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关 ->消息队列 的多级负载均衡。

架构设计

1、负载均衡算法选择

评论微博的时候选择使用写入缓冲的方式对请求削峰填谷将评论请求缓冲到消息队列里处理，消息队列的消费者服务也会讲评论内容按照微博原文将评论更新到缓存中，所以负载均衡算法选择"轮训"或"随机"。

2、业务服务器数量估算

微博评论涉及几个关键的处理：数据写入消息队列、内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），消息队列选择 rocketMq 的情况下,选择四主四从的架构,后续存储系统按照一个服务每秒处理 1000 来估算，可以延迟 20 秒处理完毕，完成 200K/s 的 TPS，需要 20 台服务器，加上一定的预留量与消息队列服务器，30 台服务器差不多了。

3、服务拆分选择

微博评论与发微博看微博时间上是同步的,因此选择将服务独立拆分出来。

微博评论的多级负载均衡架构设计

微博评论总体上与看微博一直,在后续的服务层中加入消息队列来缓冲评论写入请求并通过微博评论服务写入数据存储与缓存。

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

1、架构分析

在发生热点事件时,会有大量的读请求进入,此时通过轮训程序处理时,虽然请求已经均匀的分布到每一天机器上,但仍然可能造成部分服务器由于无法处理爆发式的请求而造成处理性能下降直至系统崩溃,所以应对热点事件时,应该首先考虑热点事件主要内容发布到 CDN 中缓存以用来满足大部分用户看微博的请求,对于微博评论,一是定时刷新部分处理后的微博评论到 CDN 中,二是设置熔断与降级策略,在请求达到设定降级阈值时将缓存中已完成刷新的内容返回,当请求量超过设定的熔断阈值时,执行熔断策略,拒绝用户请求将用户请求重定向到 CDN 路径上. 同时在运维层面,可以临时增加服务器以应对爆发增长的请求。

假设有 10%的围观用户会在热点事件发生后 60 分钟内转发、评论。

2、热点事件微博架构设计

限流：评论微博需要用户手动输入文字，丢请求对用户体验影响较大，所以尽最大可能选择不丢弃用户请求的算法。

降级、熔断：在主要业务（如发微博和看微博）出现较大性能压力时可将“评论微博”降级或熔断。