用户行为建模和性能估算

【评论】

假设平均一条微博观看人数有 100 次，有 1/10 的人会进行评论，则评论微博的次数为 2.5 亿*10=25 亿

由于大部分人评论微博的时间端和看微博是基本重合的，因此评论的平均 QPS 计算如下：

25 亿*60%/（4*3600）=100K/s

高性能计算架构

【业务特性】

评论是一个典型的写操作，并且用户发完评论并不要求马上看到，也存在自己的评论为别人刷掉，根本就看不到的情况，所以可以用缓冲。

【架构设计】

1、用户量过亿，应该要用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡

2、请求量达到 25 亿，且对实时性要求没那么高，可以考虑采用消息队列的方式。

【架构设计】

1、负载均衡算法选择

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

2、业务服务器数量估算

利用消息队列集群，将所有的评论先存入消息队列，后端服务器再进行消费；按照消息队列：业务服务器=10:1 的处理性能，则请求的 QPS=100K/s*10%=10K/s，按照每一台服务器每秒处理 500 来估算，则需要 20 台服务器；消息队列按照单机吞吐量 10 万计算，需要 10 台；按照 20%的预留量，最终需要 36 台。

高性能计算方案-整体架构设计

任务分配：分为双机房或者三机房

任务分解：将发微博和看微博分拆到不同的服务，评论和看微博放到一起，一般来说看微博和评论的时间跨度比较小，并且发评论的人比看微博的人至少少 1 个数量级

评论的多级负载均衡架构

热点事件用户行为建模和性能估算

【评论转发微博】

假设 5%的用户会在事件发生的 60 分钟内评论

【评论原微博】

很难预估，和时间的影响力和影响范围有关

业务特性

1、评论转发微博

2、评论原微博

高可用架构示意图

将所有评论都先放到消息队列中，再由后台线程来处理