模块五 评论计算架构

1. 性能预估

根据课件场景数据：

• 微博发送量为 2.5 亿条/天

• 假设每条微博有 100 人看

• 发微博与看微博重合，60%的场景发生在 4 个小时内

那么对于评论：

• 评论只能发生在看微博之后

• 假设 10%的用户会评论，包括转发

• 假设大多数人只会在评论发 1 条，对评论再次回复的数量对于评论计算没有量级影响暂时忽略

所以评论 TPS 就是看微博的 10%， 100k/s

2. 非热点时的高性能架构

评论是写操作，发评论的人会希望看到评论实时写入，但是其他用户对于及时看到评论实时性没有要求。

用户量过亿，多级负载均衡。

发评论的关键处理与发微博场景基本一致。课件指出发微博场景下一台服务器有 500TPS，对于 100K TPS 峰值需要 250 台服务器

多级负载均衡架构应与其他微博尝尽没有本质区别，DNS->F5/LVS->ngnix->网关就可以，算法可以采取 hash，将要评论的微博地址做 hash，这样同时间的评论会进入同一台服务器，方便进行服务器缓冲更新，比如有新评论写入就更新缓存，不需要查询 DB 来判断别的服务器有没有写入。

评论本身由于自身的特点，比如可以转发，可以评论加转发，可以评论之前的评论，需要显示热门评论等等，所以需要单独的服务来实现比较好。需要双机房，三机房来分配任务。缓存的话，可以继续使用 CDN 缓存，但是对于评论不需要实时更新，只是隔段时间更新即可，因为用户并不知道别人有没有发评论，自己的评论可以用本地缓存在发送成功后显示在本地。

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

使用微服务限流，同时在微服务接到请求后不做处理，直接写入消息队列做缓冲然后发回给前端显示发送成功。之后再慢慢将队列中数据写入，可以对超过一定浏览的微博建立单独 topic，普通微博可以使用公用的 topic 来减小热门微博对普通微博的影响。