模块五作业

假设每人每天发 1 条微博，每天新增微博约 2.5 亿条
假设每人每天评论 5 条微博，每天新增评论数 12.5 亿条
假设评论发送集中在早上 8：00~9：00 点、中午 12：00~13：00 和晚上 20：00~22：00 这 4 个小时，则高峰期 TPS 约为 12.5(亿)*60%/(4*3600)，50k/s
假设没人每天浏览 10 条评论，每天评论浏览数约为 25 亿
假设评论浏览集中在早上 8：00~9：00 点、中午 12：00~13：00 和晚上 20：00~22：00 这 4 个小时，则高峰期 QPS 约为 25(亿)*60%/(4*3600)，100k/s

多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡
针对发送评论，评论内容可以在用户本地缓存，通过引入消息队列缓存并异步处理评论写请求
针对浏览评论，考虑到微博本身大概率会用到 CDN 缓存，因此评论可以复用 CDN 内容缓存，这样如果覆盖 90%请求的话最终仅有 10%请求会访问到业务服务器

评论请求为无状态服务，可以发到任意服务器，因此可以采用“轮询”或“随机”算法
针对写评论，假设每台服务器每秒处理 500 请求，完成 50k/s 的 TPS，需要 20*5=100 台服务器
针对读评论，假设每台服务器每秒处理 1000 请求，完成 10k/s 的 QPS，需要 10 台服务器
最终机器数量为 110 台
任务分解，可以拆解为：
评论查询
评论接收/审核
评论写入

限流 -- 针对热点事件的评论可以采用限流，譬如请求端限流(图中用户处，譬如通过本地缓存等处理一部分用户请求)，接入端限流(譬如图中的评论接收服务器)，微服务限流
排队 -- 收到请求后并不同步处理，而是将请求放入队列，系统根据能力异步处理，如图中 Message Queue
熔断及降级处理，热点事件发生时保证核心业务正常运营，同时通过 message queue 保留请求慢慢消化