计算性能预估

微博日活 2.5 亿，假设没人每天发一条微博

微博的发布时间集中在 8：00 ~9：00， 12：00~13：00， 20：00~22：00

每条微博预计被评论 0.1 次，，则日均写评论数为 2500w，假设这个时间段发微博总量占比 60%，因此，写微博评论的 TPS 为 2500w*60%/(4*3600)=1K/S

假设每条微博评论预计被阅读 10 次，读微博评论时间与写微博评论时间基本重合，因此读微博评论 TPS 预计为 2.5 亿*10*60%/(4*3600)=100K/S

非热点事件时的高性能计算架构

业务特性分析

写微博评论是典型的写操作，不能使用缓存，可以用负载均衡

架构分析

用户量过千万，用 DNS->F5->Nginx->网关的多级负载均衡

架构设计

将评论服务与微博服务分开部署，这样可以避免热点事件产生的大量评论拖垮微博服务；同时用户对读写评论的异常容忍度比较高，并且读写评论的业务复杂度低，因此读写评论业务不用分拆服务。

由于评论与微博关联，并且写性能要求不高，因此使用 hash（微博 id）的算法进行负载均衡，将同一个微博的评论发到一个评论服务集群进行处理

使用 redis cluster 来缓存读评论，一台 redis 读性能大概是 4w~5w，按照 4W 来估算，大概需要 3 台 redis，预留 30%的量，使用 4 台 redis

热点事件时高性能计算架构

由于热点事件的 TPS 无法预估，因此，使用漏桶算法限制 TPS 的访问