一、用户行为建模及性能估算

“ 微博评论”是在“发微博”行为之后的业务行为，一般“微博评论”行为在“发微博”行为后的一段时间内进行，因此“ 微博评论”的业务场景可以基于“写微博”业务场景下考虑。

假设平均每个微博有 10 条微博评论，且微博评论大部分在发微博之后的一个较短时间内完成，可以认为微博评论与发微博的发生时间类似，只是发送内容较少，且发生频率是写微博的 10 倍。

按照《模块 5 第 6 课》中，“发微博”每日发送量 2.5 亿，TPS 为 10K/S。基于这个数据前提下，评估“ 微博评论”每日发送量 25 亿，TPS 为 100K/S。

“ 微博评论”和“发微博”的一个重要区别是，“发微博”是一个实时行为，发送内容较多；“ 微博评论”实时性没有那么高，且发送内容较少。

二、架构分析

本次架构分析仅分析高性能高可用，不考虑存储性能。

根据用户行为建模分析，“ 微博评论”是个典型的写操作，可以用负载均衡。由于写操作不要求实时性，可以考虑用缓存写的方式，比如队列。

由于用户量过亿，应该要用多级负载均衡架构，覆盖 DNS->F5->nginx->网关->应用的多级负载均衡。

由于实时性要求不高，使用缓存写，可以在应用层增加消息中间件。

三、架构设计

1、负载均衡算法选择

“ 微博评论”依赖于“微博”的 ID,微博 ID 也在“ 微博评论”的请求报文之中，任意服务器均可处理。因此，负载均衡算法采用“轮询”或者“随机”算法，将请求分配到任一应用服务器上。

2、（写缓冲）消息中间件选择

消息中间件的使用，仅仅是为了写缓冲的作用，一般消息中间件如 rocketMq、kafka、rabbitMq 均可使用。由于无特殊要求，采用最常用的 kafka 中间件。

3、业务服务器数量估算

《模块 5 第 6 课》中“写微博”每台服务器 500TPS，使用 25 台服务器，以满足 10K/S 的 TPS。

“ 微博评论”虽然写入量是“发微博”的 10 倍，但是由于可以缓冲写，不必要求服务器是“写微博”的 10 倍。“ 微博评论”的服务器使用量也用 25 台，每台服务器外加三台 kafka 服务器作为消息中间件集群用作写缓冲。应用服务器中有两个进程，一个是“写缓冲”进程，一个是“读缓冲业务处理”进程。

4、由于“ 微博评论”的写操作与“发微博”的实时性不一样，重要性级别也不一样。因此考虑将“ 微博评论”应用与“发微博”分开，独立部署。

四、架构设计图

基于以上分析，设计“微博评论”的高性能高可用架构图如下：

五、热点事件

“微博评论”热点事件和“写微博”的热点事件场景重合，“写微博”导致的“转发微博”事件可以用“漏桶算法限流”丢弃一些“转发微博”行为。但是，“微博评论”热点事件不可采用丢弃方式。这是两者之间的区别。

以上的架构设计使用 kafka 实现了写缓冲的机制，具备限流的作用，起到了具备“削峰”的效果，能够满足热点事件场景下的高计算高可用要求。