架构实战营作业五

作业要求：

微博评论场景分为写评论和读评论两个场景。场景分析的数字基于课程中提到的写微博和读微博的分析，即：写微博 TPS 在 10k/s，读微博 QPS 在 1000k/s。

为了应对热点话题微博，不建议分开两套服务，而是整合到一套架构里面。做好预防设施。

一. 写微博评论：

1. 性能预估：

写评论 TPS 比发微博的流量高，比看微博的要低。介于中间，也就是 10k/s 到 1000k 之间，假设是 100k/s。

2. 写入性能问题：

据以上分析，写评论的 TPS 比写微博高 10 倍，同时为了应对热点话题的大流量冲击，可以使用漏斗算法进行限流，限流队列设为 10 万，基本容纳常规流量的量。

写评论实时性要求不如写微博高，晚一点看到评论也关系不大，所以可以使用缓存的结构，以提高写评论的性能。这里采用 redis cluster。先写 DB 再写缓存，首先保证评论落库。如果 DB 写入失败则不写缓存；如果 DB 成功缓存失败，则忽略，可以容忍少量的缓存不一致，待后面缓存过期或被动更新。

3. 负载均衡算法，采用随机/轮询算法，

4. 服务器数量估算：如果每个服务器每秒处理 800 个请求，完成 100k 的 TPS，需要 125 台服务器，加上一定的预留量，分配 150 台服务武器。

5. 高可用架构可以借鉴发微博的整体架构：四级负载均衡。（绿色模块名称“发微博”视为“发评论”）

二. 看微博评论，使用 CDN

1. 性能预估：看评论的流量应该比看微博本身要低，但至少写评论的人会看一下自己的评论，所以假设看评论和写评论的 TPS 一样，都是 100k/s。

2. 高可用：同时为了应对热点话题，需要准备限流设施，达成高可用性。同写评论类似，也采用漏桶算法。如下图：

整体的高可用架构和看微博类似，这里直接采用课程的图表：（绿色模块名称“看微博”视为“看评论”）

负载均衡算法，采用随机/轮询算法，

3. CDN 能够承担 90%左右的流量，剩下 10%的流量，则为 100k/s * 10%=10k/s。假设单台服务器能处理 1000/s，则需要服务器 10 台，安排 50%的预留量，最终分配 15 台机器。整体的缓存系统体系，可以借用看微博的。其中的分布式缓存在写评论时有提到。