课程学习笔记
详见：https://www.processon.com/view/link/6166fa560791290cc7898ff0
设计微博系统中“微博评论”的高性能高可用计算架构。
【作业要求】
基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容:
1. 计算性能预估(不需要考虑存储性能);
2. 非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务;
3. 热点事件时的高可用计算架构。
【提示】
1. 分析方法对照“看微博”和“发微博”的案例。
答：参照微博发展报告，日活用户按照 2.24 亿计算。
- 用户行为建模和性能估算
1.【发评论】
相比发微博，用户发评论的概率一般会略高一点，假设每条微博会被 2 人评论，加上博主回复的评论，每条微博则附带 4 条评论，参照课程每天 2.5 亿条新微博的估算，则微博评论每日的发送量大约是 2.5 亿*4=10 亿条。
与发微博场景类似，大部分的人发评论，集中在早上 8:00~9:00 点，中午 12:00~13:00，晚上 20:00~22:00，假设这几个时间段发微博总量占比为 60%，则这 4 个小时的平均发微博的 TPS 计算如下:10 亿 * 60% / (4 * 3600) ≈ 40 K/s。
2.【看评论】
大多数情况下，评论仅评论者与被评论者双方看，故假设每条评论，除了双方，还有其他相关人查看，预估每条评论的查看人数为 10 人，则看评论的次数为每天 100 亿次。
大部分人看评论的时间与发评论的时间重合，预计在业务高峰期，看评论的 QPS 结果为：40K/s*10=400K/s。
- 架构设计
1.【发评论】
- 业务特点分析：发评论是一个写操作，相对于主帖，评论的实时性要求相对低，可以通过写缓冲，再通过负载均衡分摊请求的方法，将缓冲写入系统库。
- 架构分析：用户量过亿，需要采用多级负载均衡架构，覆盖 DNS-F5-Nginx-API 网关的多级负载均衡。
- 架构设计：
- 负载均衡算法选择：发评论时，登录状态已存在于分布式缓存当中，请求发给任意后端服务器均可以，可以选择轮询算法/随机算法实现；
- 业务服务器数量估算：微博评论相比于主帖，内容更短，且一般不会带图，假设每个服务器每秒处理 800 个请求，针对 40K/s 的 TPS，需要 50 台服务器，预留 10 台备用，则大约需要 60 台服务器。
2.【看评论】
- 业务特点分析：看评论是一个典型的读操作，且请求量较大，故可以采用缓存架构+负载均衡架构实现。
- 架构分析：用户量过亿，需要采用多级负载均衡架构。请求量到达 100 亿，故 CDN 也不可或缺。
- 架构设计：
- 负载均衡算法选择：看评论时，评论已经加载到 CDN 或者缓存数据库里，负载均衡算法采用最简单的轮询、随机即可。
- 业务服务器估算：CDN 承载 90%的流量，剩下 10%的请求进入系统，则请求的 QPS 为 400K/s*10%=40K/s，由于读评论的逻辑比较简单，单台设备的处理能力是 1500/s，故 27 台服务器即可满足业务需要，预留 20-30%，约 8 台，故总共 35 台服务器可以满足看评论的业务需求。
架构图
1.【发评论】
https://www.processon.com/view/link/6167081d63768921fa1e4376
2.【看评论】
https://www.processon.com/view/link/6167073b7d9c086651384458
