微博系统中”微博评论“的高性能高可用计算架构

·       评论微博-计算性能预估：

o   用户量：日活 2.24 亿

o   性能估算：假设平均每条微博有 5 人评论， 评论时间通常集中在早上 8 点-9 点，中午 12 点-13 点，晚上 8 点-10 点，一天总共 4 小时左右。假设这段时间评论微博量占比 60%。

2.24*5*60%/(4*60*60) =50k/S

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

【业务特性分析】

·         评论微博也是一个典型的写操作，因此不能用缓存，可以用负载均衡。

【架构分析】

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

【架构设计】

1. 负载均衡算法选择

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

2. 业务服务器数量估算

·         跟发微博一样，评论微博也涉及以下几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 50K/s 的 TPS，需要 100 台服务器，加上一定的预留量，120 台服务器差不多了。

微博高性能计算架构-整体架构设计：

微博的多级缓存整体架构

由于评论微博和发微博一样没有缓存，因此微博业务整体的缓存架构，就是看微博的多级缓存架构

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

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

【评论微博】

·         造成热点事件的微博自己只有 1~2 条，但是用户围观后会有很多评论，假设有 20%的围观用户会在事件发生后 60 分钟内评论。用户的评论不需要及时性，因此可以使用写缓冲。

微博评论热点事件计算高可用架构示意图：