性能估算

【微博评论】

由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，其中又平均有 10 人会进行评论（包括评论互动）。则评论微博的次数为：

2.5 亿 * 10 = 25 亿

大部分人评论微博的时间段和发微博的时间段基本重合，因此评论微博的平均 QPS 计算如下：

25 亿 * 60 / (4 * 3600) = 100K/s

PS. 我觉得我评论的比例估的有点高，但是个人觉得微博评论是体现平台用户活跃度很好的一个指标。所以我觉得在资源预估上适当放肆一些比较好。

非热点事件时高性能计算架构设计

【业务特性分析】

评论微博同样是一个典型的写操作，但是和发微博不同，用户发完评论并不需要立即查看对应评论。所以可以使用消息队列 + 负载均衡。

【架构分析】评论微博也是核心功能，因为整体量级、所需要的架构组件栈也和发微博、看微博的要求级别不太一致，所以还是推荐进行服务拆分。而且因为发微博、看微博的意见使用了全链路的负载均衡，所以复用现有技术栈即可（覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡），直接在服务器集群中进行服务器的区分，网关集群以上的负载均衡直接复用。

【架构设计】

评论微博和发微博一样，也涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖缓存）、数据写入缓冲（依赖消息队列）。但是因为评论微博时效性并没有发微博这么高，每个服务可以先写到消息队列，然后再异步刷到存储系统。评论数据写 MQ 单个服务处理按 1W/s 的 TPS 计算，需要 10 台服务器。MQ 同步到存储，同样按每个服务每秒处理 500 来估算，完成 100K/s 的 TPS，需要 200 台服务器，因为使用了 MQ 当做缓冲，且评论时效性要求并没有那么高，可以预留 5 台写 MQ 机器，10 台同步存储服务器。一共 215 台差不多。

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

热点事件指某个大 V 或者明星爆料或者官宣，虽然只有一两条微博，但引起大量用户在短时间内访问，给系统造成很大压力。

【架构设计分析】

相对于转发微博，当某个热点事件发生时，当前微博评论应该是“主战场”。所以设计可以参考转发微博，但是指标要求需要高于转发微博。

高可用架构示意图：