架构训练营作业 5

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

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用

计算架构，包括但不限于如下内容：

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

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

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

【用户量】

1. 2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）。

【用户行为建模和性能估算】

评论微博是一个看得多发得少的业务，假设平均每天每人评论 1 条微博则微博每天的评论送量约为 2.5 亿条。

大部分的人评论微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段评论微博总量占

比为 60%，则这 4 个小时的平均发微博的 TPS 计算如下：

2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s

与发微博基本是一个量级

【业务特性分析】

评论微博是写操作，因此不能用缓存，可以用负载均衡；考虑到评论微博没有发微博实时性要求那么高，可以使用写缓存 buffer。

【架构分析】

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡。发微博与评论微博的访问量级相差不大；业务处理相似，关键处理流程都涉及：内容审核、数据写入存储、数据写入缓存

；可以公用发微博服务，不需要拆分独立的评论微博服务。

【架构设计】

1. 负载均衡算法选择

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

2. 业务服务器数量估算

不拆分独立的评论微博服务，因此机器数量跟发微博一致

3.写缓冲设计

评论微博实时性要求没有发微博那么高，引入写缓冲，这里使用消息队列，评论微博写入存储后，发送消息，异步处理后序流程，比如更新缓存

【高性能整体架构设计】

【热点事件高可用】

热点事件发生时，同一条热门微博，短时间内会涌入大量的评论请求，考虑对“评论微博”限流；

由于评论是用户操作行为，避免用户的疑虑，尽量不能拒绝用户的评论，考虑使用“漏桶算法”；

评论微博实时性容忍度要高些，相对于发微博，考虑使用写缓存，引入消息队列异步处理；