计算性能评估

1. 2020.9 月月活 5.11 亿，日活 2.24 亿(参考《微博 2020 用户发展报告》)，故预计日发微博数为 2.5 亿；

2. 假设每条微博评论数为 10 条，故日发微博评论 25 亿；

3. 假设发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，而发微博和发评论的时间基本重合，假设这几个时间段发评论总量占比为 60%，故 4 小时为发微博业务峰值：25 亿 x 60% / 4 / 3600 = 100k/s

4. 假设看微博和评论的时间段类似，且所看评论一般为前 50%（即前 5 条评论），故估计量级为：看微博数量 x 5 x 2（冗余量） = 10M/s

非热点事件高性能架构

可以从性能评估中看到，虽然服务量级的差距大，但是由于读评论的架构中引入了 CDN，所以读写比例降为了 10:1，并且可以在读评论时提供上层的缓存能力，故以下将发评论与看评使用相同的服务；

发评论高性能框架

1. 采用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡；

2. 由于评论会针对某一条微博进行评论所以可以在业务网关上实现双重 hash，将评论发送到较为固定的业务集群上，可以更好的利用业务机器上的缓存；

3. 由于评论不需要实时性，所以可以使用漏桶，并且对评论进行批量处理，提高单机的 TPS 能力；

4. 由于评论的字数一般都不会过长，加上后端的批量方案，可以预估单服务 TPS = 2k/s；

5. 所以加上 20%冗余量，需要 60 台设备；

读评论高性能框架

1. 采用多级缓存架构，APP/浏览器缓存 > CDN 缓存 > WEB 容器缓存 > 进程内缓存 > 分布式缓存；

2. 与发评论的负载均衡策略与参数一致，将读流量引导至一样的业务集群上，是的中间的 web 容器缓存与应用内缓存更容易被 match 到；

3. 此时假设 CDN 能够承载 90%的用户流量，nginx 能够承载剩余流量的 50%，剩余 5%总流量进入业务服务，但此时会完全命中进程内缓存；

4. 由于读写用到同一组服务器，为防止读写流量产生相互影响，加上 20%冗余，发评论与读评论总共用到 72 台设备；

热点事件高可用架构

1. 使用动态扩缩容技术与部分限流手段可以实现热点事件高可用的能力；