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

1.    计算性能预估

微博用户量预估参考微博 2020 用户发展报告，日活量 2.24 亿

用户行为建模：

用户行为是评论微博。

假设微博每天的发送量为 2.5 亿条

假设平均一条微博观看人数有 100 次

2.5 亿 * 100 = 250 亿

性能需求计算

假设看微博的时间段有 60%集中在上下班和午休的 4 小时，

QPS = 250 亿 * 60% / (4 * 3600 ) = 1000K/s

假设看微博的人之中有 10%的人评论微博

1000K/s * 10% = 100K/s

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

微博评论是写操作，可以用漏桶做写缓冲，慢慢异步处理，因为评论不必立刻看到。需要加上负载均衡架构。

选择 4 级负载均衡，算法选择用 Hash 哈希算法，这样可以紧密绑定所看微博服务和相关微博评论，不必拆分成独立的微博评论服务。

按照一个服务每秒处理 1000 来估算，完成 100K/s 需要 100 台服务器，假设写缓冲可以缓冲 50%请求，那只需要 50 台服务器，加上 20%预留量，最终需要 60 台服务器。

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

热点事件的微博评论量很难预估，只能预防。可以用漏桶算法做限流，先把微博评论放进消息队列，把消息队列长度设置成很大，比如 100 万，后台异步处理。如果微博评论请求实在太多了，可以自动熔断微博评论，以保住核心业务高可用。