架构实战营 模块五 作业
用户量
2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）
微博评论
由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，则观看微博的次数为：2.5 亿 * 100 = 250 亿
假设每 100 次会发一次评论，每天产生的评论条数为：2.5 亿 * 100 / 100= 2.5 亿
评论微博的人数与看评论的人数，和发微博的人一样集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段的评论数总量占比为 60%，则这 4 个小时的平均发评论的 TPS 计算如下：2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s； 这 4 个小时的平均看评论的 TPS 计算如下：250 亿 * 60% / (4 * 3600) ≈ 1000 K/s
发评论
业务特性分析
发微博是一个典型的写操作，因此不能用缓存，可以用负载均衡
架构分析
用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。
架构设计
负载均衡算法选择：发评论的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此发评论的时候，可以将请求发送给任意服务器，可以选择“轮询”或者“随机”算法。
业务服务器数量估算： 和发微博类似，涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因
此按照一个服务每秒处理 500 来估算，完成 10K/s 的 TPS，需要 20 台服务器，加上一定的预留量，25 台服务器差不多了。
发评论多级负载均衡架构设计
看评论
业务特性分析
看评论和看微博一样，是一个典型的读场景，发了后不能修改，因此需要适合的缓存架构，同时由于请求量很大，负载均衡架构也需要。
架构分析
用户量过亿，需要应用多级负载均衡架构
请求量达到 250 亿，应该要用多级缓存架构，需要用到 CDN
架构设计
负载均衡算法选择：与看微博类似，游客可查看评论，因此可将请求发送给任意服务器，选择“轮询”或者“随机”算法。
业务服务器数量估算： 假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博的请求进入系统，则请求 QPS 为 1000K/s * 10% = 100K/s，由于读取微 博的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 100 台，按照 20%的预留量， 最终机器数量为 120 台。
看评论多级负载均衡架构设计
看评论多级缓存架构设计
任务拆分
发评论和看评论，与发微博和看微博一样，都是看的人数远大于发的人数，所以需要把发评论和看评论也拆分为独立的服务
关于突发热点事件
根据“既然无法预估，那就做好预防！”的核心架构思想
【发评论】
可以考虑限流，使用“漏桶算法”，避免请求丢失，可以考虑使用写缓冲，使用消息队列或者 kafka 进行削峰
【看评论】
和看微博一样可以考虑“多副本缓存”，原有的缓存架构已经采用了应用内的缓存，总体上来看，缓存热点问题不一定很突出，另外可以考虑针对看评论进行降级，采用“令牌桶算法”来限制大量请求进入
还未添加个人签名 2018.04.25 加入
还未添加个人简介
评论