微博评论高性能高可用的设计

1.评论计算性能预估：

根据微博 2020 年的推算有大约 2.5 亿日活跃用户，假设每天每个人看 100 条微博，那么就是 250 亿条数据，

假设他在看的途中，有百分之 10 的概率去写评论，而且是评论一条数据，那么理论上评论的数量是

250 亿 * 0.1 = 25 亿

发表评论的时间，大概在 8：00-9：00 点，中午 12：00-13：00，晚上 20：00-22：00，假设这几个小时评论的总量占用 60%，那么这 4 个小时的 tps 计算：

25 亿 * 0.6 / 4(小时) 大约 10k/tps

2. 非热点事件的高性能计算架构，是否需要拆分成单独服务。

从热点事件和非热点数据而已，热点事件的访问肯定比非热点事件的多而且并发大。但是如何区分热点数据和非热点数据，这个是很难预估的。所以拆分成热点数据服务和非热点数据服务，是不需要的。

3.热点事件的高可用架构

热点事件主要体现在用户的访问和评论，转发上。

针对是热点数据，可能用户读取的并发上是最重要的事件。

热点事件

业务特性：

体现在数据的访问并发上，而且是突然一下子就飙升的访问，需要进行负载均衡，缓存使用和过载保护。

架构分析：

访问达到亿级别，那么应该使用多级缓存。

推算请求访问量，如果达到百万级别/QPS，那么缓存是设计的重点，让大部分请求在 CDN 上，需要针对 CDN 进行带宽的动态的扩容。

架构设计：

1.负责均衡算法选择，选择轮询或者随机

2.业务服务器的过载保护

假设热点数据请求达到 1000w/qps,理论上 CDN 过滤掉 90%的请求，那么 1000w/qps * 0.1 = 100w/qps 的请求会到达下一级的复杂均衡服务器。

由于我们的服务器理论性能是 1000/qps，而我们 100 台服务器能承载的服务请求是 100* 1000qps = 10w qps，那么我们在网关层，比如 Nginx 层的时候，需要进行推算，如果我们入口 CND 和 LVS/F5 都能抵抗 100wqps 的请求，那么我们需要在 2 级负责均衡 Nginx 的时候，进行请求丢弃熔断保护。重要才能进行热点数据的高可用。