1、性能估算

1.1 看评论

因为在看一条微博详情的时候，同时会自动加载第一页评论列表信息。因此看评论的 QPS 与看微博的一致：1000K/s

看评论可以和看微博放在一个服务中，因为这两个业务关联性很强，缓存可以和微博的缓存放在一起，缓存微博内容并且缓存前一千的评论，这样用户在看到微博后不用请求后端即可查看评论，极大减少后端请求压力。

1.2 发评论

考虑到评论是一个看得多发的少的业务，假设在刷评论的人中只有 1%人会发表评论，则发评论的 TPS 计算如下：1000K/s * 1% = 10K/s

按照一个服务每秒处理 500 来估算，完成 10K/s 的 TPS，需要 20 台服务器，加上一定的预留量，25 台服务器差不多了。

3、热点事件

【业务特性分析】

1. 写评论

热点事件发生后，用户都会看到第一时间写评论，希望自己的评论曝光度更高，但是一般发完评论之后一般不会再去一直滑动找自己的评论，所以写评论可以接受一定的延迟

2. 读评论

热点事件发生后，绝大部分请求都落在了导致热点事件发生的那一条微博的评论上面。

【架构设计分析】

1. 写评论

写评论一般都是用户原创，丢弃会产生不好的体验，需要尽量少丢弃请求，考虑用“漏桶算法”，最好使用类似 kafka 这种超大队列，防止热点事件发生时队列长度不够丢弃请求。

2. 看评论

很明显，热点事件微博存在缓存热点问题，可以考虑“多副本缓存”，由于原有的缓存架构已经采用了“应用内的缓存，总体上来看，缓存热点问题其实不一定很突出。