评论微博

通常看发评论会伴随看微博而来，我们假设每 100 人看微博就会有一个人发表评论,

看评论的平均 QPS 为: 1000k/s(看微博) 热点事件假设峰值为平均的 5 倍: 5000k/s

则发评论的平均 QPS 次数为： 1000k/s(看微博) / (100) = 10k/s 热点事件假设峰值为平均的 5 倍: 50k/s

业务特性分析

由于看评论有新增或排序需求, 不使用进程内缓存, 统一由计算系统更新分布式缓存, 同时由于请求量很大，也需要负载均衡架构。

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

架构分析

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

架构设计

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

2. 业务服务器数量估算

• 发表评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 1000 来估算，完成 50k/s 的 TPS，需要 50 台服务器，加上 20%的预留量，使用 60 台服务器。由于评论的实时性不高(还需要经过审核), 可以利用写缓冲或是消息中间件削峰, 实际上服务器数量可以在减少

• 看评论架构上与看微博类似且有時間局部性, 可以與看微博共用服務器，不同的是会增加新评论或是排序, 针对热点(大 v)需要服务器做聚合计算后, 主动更新缓存

前端限流

避免一次读取太多评论, 一次只读取 n 个评论

针对热点事件的额外设计

• 分开大 v 与一般用户的服务器集群

• 避免缓存穿透, 採用随机失效

• 避免缓存雪崩, 採用后台更新

• 避免缓存热点, 多副本缓存

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

评论微博的多级缓存架构

微博热点事件计算高可用架构