模块 5 作业

用户行为建模和性能

根据第 6 课的案例中的数据：日活：2.5 亿/人，我们假设如下：

高峰 4 小时：30%人发微博、60%人看微博、10%评论微博

其他时间段（10 小时）： 30%发微博、60%人看微博、10%人评论微博

发微博的数量：

TPS：2.5 亿 * 30% / (4 * 3600) ≈ 5.5 K/s（高峰 4 小时）。

TPS：2.5 亿 * 30% / (10 * 3600) ≈ 2.1 K/s（其他 10 小时）。

评论微博的数量：

TPS：2.5 亿 * 10% / (4 * 3600) ≈ 1.8 K/s（高峰 4 小时）。

查看评论:

QPS: 2.5 亿 * 10*10% / (4 * 3600) ≈ 18 K/s（高峰 4 小时）。

发评论

业务特性分析：

发评论是一个典型的写操作，因此不能用缓存，可以使用负载均衡

架构分析：

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

架构设计：

1 负载均衡算法选择：发评论的时候依赖登录状态，登录状态一般都是保存在分布式缓存中，因此发评论的时候，则请求发送给任意服务器都可以，这里选择轮询或者随机

2 缓存选择：

因为发评论不需要实时处理，因此可以把评论内容暂时存放到 app 或单体页面中，后端收到请求后把数据存放到消息队列中（使用写缓冲减少请求量降低服务器压力），最后业务系统处理。所以需要页面缓存和服务器缓存（如消息队列）

2 业务服务器数量估算：

发评论设计几个关键的处理：内容审核（依赖审核系统），数据写入存储（依赖存储系统），数据写入缓存（依赖缓存系统），假设 kafka 能接受的最大积压数据（桶的总量为 2G），每个评论大小为 100 个汉字，则最多可以存储 1 千万条评论，因此按照一个服务每秒处理 500 来处理 ,要 3 台服务器，加上一定的预留量，5 台服务器。

微博看评论

选择“hash”算法，假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博的请求进入系统，则请求 QPS 为 18K/s * 10% = 1.8K/s，由于读取微 博的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 2 台。

架构图：

缓存架构：

热点微博的评论高可用的计算框架

【业务特性分析】

热门微博写评论：漏桶算法限流，可以放在消息队列里慢慢写入数据库，在上述架构中，已经使用了写缓冲应对，可以使用和普通写评论同样的架构。

热门微博看评论：可以读不到数据，降级