用户行为建模和性能预估

评论微博预估是看微博的人数的一半，因此我们假设一条微博平均有 100 人评论，则评论微博的次数为：

2.5 亿*100*50%=125 亿

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

125 亿*60%/(4*3600)=500 K/s

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

【业务特性分析】

发表评论是一个写操作，及时性要求不需要特别高，因此可以引入用缓存，可以用负载均衡。

【架构分析】

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

【架构设计】

1. 负载均衡算法选择

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

2. 业务服务器数量估算

评论微博引入消息队列，消息先写入消息队列

评论微博消息写入消息队列，处理能力比写微博要高，因此按照一个服务每秒处理 800 来估算，完成 500K/s 的 TPS，需要 650 台服务器，加上一定的预留量，700 台服务器差不多了。

【评论微博多级负载均衡架构】

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

热点时间可以引入更多副本，缓存里 key 增加多个多个，比如 key#1、key#2 分摊读取评论的压力，防止被热点事件打挂，同时需要动态扩容更多的机器缓解读取和评论的压力