模块五作业

业务特性分析

评论分为发评论和看评论，看评论属于读请求，用缓存，用负载均衡架构。写评论属于写请求，不采用缓存，采用负载均衡架构。

架构分析

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关 ->消息队列 的多级负载均衡。

性能估算

发评论

假设一人一天发 0.5 条评论，则评论每天发送量为 1.2 亿。大部分人发评论的时间跟看微博的时间一致，分布在 8:00-9:00 12:00-13:00 20:00-22:00 总量占比为 60%，4 个小时平均 tps 为，1.2 亿*60%/（4*3600）= 5k/s。

看评论

假设一条评论观看次数为 50 次，则观看评论的次数为 2.5*50=125 亿。大部分看人评论和发评论的时间一致。所以复算 qps 为 125 亿*60%/（4*3600）=500k/s。

架构设计

服务拆分

“发评论”和“看评论”最好拆分服务，因为看评论的量远大于发评论，拆开可以避免看评论太多导致发不了评论。

存储架构

设计要点：

• 写评论的存储架构采用分片架构

• 读评论的存储架构采用集群选举

计算架构

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

发评论

• 负载均衡算法选择

负载均衡算法采用轮询或者随机算法。保证评论高可用，应该采用漏桶算法写缓冲，牺牲了时间，来保证每个评论都能显示。

• 业务服务器数量估算

发评论和发微博的处理步骤基本一致，这里模仿发微博的，因此按照一个服务每秒处理 500 来估算，完成 5k/s 的 tps 来估算，需要 10 台服务器，加上 25%的预流量，为 15 台。

看评论

• 负载均衡算法选择

负载均衡算法采用轮询或者随机算法，采用多级缓存架构，跟看微博一样，cdn 为缓存架构的核心。

• 业务服务器数量估算

按照 ppt 中的，cdn 能够承载 90%的流量，那么剩下的 10%进入系统，则请求 qps 为 50k/s，假设单台业务服务器处理能力为 1000/s，则机器数量为 100 台，按照 20%的预留量，最终机器数量 80 台。

热点事件高可用计算架构

• 负载均衡算法采用负载优先的算法，保证服务器高可用，不会宕机。

• 保证评论高可用，应该采用漏桶算法写缓冲，牺牲了时间，来保证每个评论都能显示。

• 必要时也开采取服务降级的手段，保证看评论优先级。