架构训练营 week5 作业

设计微博系统中“微博评论”的高性能高可用计算架构。

• 计算性能预估（不考虑存储性能）

微博评论的性能需要预估两方面内容：写评论和看评论

• 看评论

• 看评论的行为分为 2 种，一种是看微博下的评论列表（仅前几条），另一种是点查看所有的 xx 条评论。我们假设看评论的行为与看微博的行为时间点完全重合，并且每个用户会看 20 条微博下的评论信息。则看微博评论的次数为 2.5 亿 * 20 = 50 亿。 而看评论的平均 QPS 为 50 亿*60%/(3600*4)=200K/s

• 写评论

• 我们假设写评论的时间分布与发微博的一样，并且也是 60%的评论是在 4 个小时内写的，并且同时我们假设，每个人在 4 小时内会写 10 条微博下的评论信息。则写评论的 TPS 为发微博的 10 倍，100K/s。

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

• 发评论设计几个关键处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 100K/s 的 TPS，需要 200 台服务器。按照 20%的预留量，则需要约 250 台。

• 假设 CDN 能够承载 90%的用户流量，那么剩下 10%的看评论的请求进入系统，则请求 QPS 为 200K/s * 10% = 20K/s，由于读取微博的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 20 台，按照 20%的预留量，最终机器数量为 25 台。

• 而因为要发评论，必须要看前面几条微博评论，所以发微博和看微博的行为相关性很高，并且发微博要写缓存，而看微博则要读缓存，跟缓存的相关性也都很高，并且预估的性能数量级差距并不是很大，因此个人觉得不需要将两者的服务器分开。所以最终可以用 250 台服务器来服务发评论和看评论的操作

多级负载均衡架构图如下：

多级缓存架构图如下

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

• 发生热点事件的时候，会有大量的用户对于同一条微博进行评论的发布和查看，会导致服务器负载过高，并且当缓存由于某些原因失效的时候，会导致缓存击穿的情况出现。

• 对于看评论，出现大量请求的应对方式与看微博一样，发现热点事件之后，对于热点微博的缓存部署多副本的缓存，让缓存的请求可以打到很多个缓存服务器上，降低单个缓存服务器的负载。如下图，假设微博 1 成为热点微博，它的评论 1-1,1-2,1-3 也会成为热点的数据，因而缓存服务器 1 会不堪重负。如果将它的数据复制到其他服务器，并且采用一定的路由规则将请求路由到其他服务器，则可以缓解这样的情况。

• 对于写评论，因为对于实时性要求较低，可以使用 kafka 等消息队列来缓存大量写评论的请求。即使是让用户的评论出现暂时的延迟，也不至于让服务器出现崩溃的情况。