微博评论高性能高可用计算架构

微博评论高性能高可用计算架构

用户量预估：

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

用户行为建模：微博评论

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

大部分是早 8-9，中午 12-13，晚上 20-22，假设占比 60%

每人看得微博里面，每 10 条留 1 条评论，则每个微博有 10 条评论

2.5 亿 10 * 60% / (4*3600) = 100k/s TPS

评论微博

[业务特性分析]

评论微博是一个写操作，并且和缓存强绑定，需要缓存，需要负载均衡

[架构分析]

用户量过亿，应该要用多级负载均衡架构

[架构设计]

负载均衡算法选择

评论是对应某条微博得，用微博 id 做 hash 负载均衡

业务服务器数量估算

内容审核、数据写入存储、数据写入缓存，按一台服务器处理 500 来估算，需要 200 台，加上预留量，250 台差不多

评论和微博虽然是强绑定，但是缓存里面只需要最近得几条即可，更多得评论可以等用户请求得时候，用随机或者轮询的负载均衡去拉取出来。

非热点事件：非热点事件，用 id 的 hash 负载均衡已经可以很均衡，不需要拆分

热点事件：因为是微博得唯一 id 做 hash 得负载均衡，热点事件发生时，极容易导致某些机器过载，所以要针对某些账号做热点处理，方便引流。