作业要求

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容：

1. 计算性能预估（不需要考虑存储性能）；

2. 非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务；

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

计算性能估算

背景

发评论

看评论

高性能计算架构设计

发评论

业务特性分析

架构分析

架构设计

发评论的场景，依赖的登录状态保存在分布式缓存中；关联的微博id客户端知晓，并由客户端传入，所以服务端无状态，可以任意缩扩容，可以处理任意“发评论”的请求。这里选择“轮询”或者“随机”算法。

发评论主要涉及以下几个处理步骤：数据写入缓存（依赖缓存系统）、数据批量写入存储（依赖存储系统），其业务处理相较于“发微博”更简单，因此可以按照一个业务服务器可处理的最高 TPS 为 1000 进行估算，完成 100K TPS 的处理，需要 100 台服务器，按照 20% 的预留量，需要 120 台服务器。

看评论

业务特性分析

看评论是一个典型的读场景，由于评论发表后不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

架构分析

架构设计

1.负载均衡算法选择

由于任何人都可以看评论，评论之间，以及评论与其他业务之间无依赖关系，所以服务端无状态，可以任意缩扩容，可以处理任意“读评论”的请求。基于空间局部性原理，为了增加进程内缓存的命中率，这里选择“一致性Hash”算法，将同一条微博的看评论请求转发到同一台或同一组服务器处理，保证较高缓存命中率的同时，不影响应用的伸缩性。

2. 业务服务器数量估算

假设 CDN 能够承载 90% 的用户流量，那么剩下 10% 的读评论请求进入系统，则请求 QPS 为 200K，由于读微博的业务场景简单，主要是读缓存系统，因此假设单台业务服务器处理能力即 TPS 为 1000，则机器数量为 200 台，按照 20% 的预留量， 最终机器数量为 240 台。

整体架构设计

服务拆分

微博评论的多级负载均衡整体架构

微博的多级缓存整体架构

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

用户行为建模和性能估算

术语含义

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

发评论

造成热点事件的微博本身数量极少，但是大量用户会在短时间内访问，同时会在热点微博下面出现大量评论，给系统造成极大压力。

看评论

用户看热点微博的同时，极其可能大量浏览后面的评论，且看微博和看评论有极强的相关性。由于看微博的流量很难预估，故看评论的量也很难预估。

业务特性分析

发评论

由于服务器无状态，负载均衡算法选择“轮询”或者“随机”算法，故热点事件发评论场景与普通发评论场景并无明显差异。

看评论

由于负载均衡算法采用“一致性Hash”算法，同一条微博的看评论请求可能发往单台或单组服务器处理，导致单台或单组服务器处理压力极大。

架构设计分析

发评论

看评论

计算高可用架构