模块五作业

需求分析：

一 . 非热点高性能方案

微博评论非为 写评论和看评论两部分。

1.性能估算

写评论

按照每天 2.5 亿条微博，每个微博下面有 30 个评论，写评论的时间点和发微博的时间点类似，

计算 TPS=2.5 亿*60%*30=30 万/s

看评论

看微博和看评论基本是在差不多的时间点发生的，每个微博下的评论观看次数 100，有 30%的微博

评论会被看

QPS=250 亿*60%*60%/(4*3600)=30 万/s

看评论和写评论基本是在同一个微博下的，所以不考虑拆分

2.业务特性分析和分析

写评论

2.1 写评论考虑使用缓存，实时性看要求不高，使用多级缓存

用户量过大，使用多级负载均衡

2.2 架构设计

负载均衡算法：评论是针对微博的，负载均衡考虑微博 id 进行 hash 算法

业务服务器数量：按照数据审核，数据写入缓存，数据写入存储

一台服务器 500/s 的写入，完成 30 万 TSP 大概需要 600 台服务器，预留 50 台，一共 650 台

负载均衡采用三级负载（去掉 F5/LVS）：DNS->Nginx>网关

多级缓存采用三级缓存：app>web 容器>分布式，去掉 CDN，成本考虑，去掉应用内缓存

是应为一个微博下的评论查询的符合空间局部性，需要拿出来相邻的数据，比如返回 10 条评论（考虑到看看评论）

看评论

看评论和写评论分析过程一样，不同的时机器数量：一台服务器 1000/s 的读取，需要 300 台，预留 50 台，一共 350 台

所以评论的高性能计算方案是：

机器台数 650+350=1000 台

负载均衡采用三级负载：DNS->Nginx>网关

多级缓存采用三级缓存：app>web 容器>分布式

采用任务分配：三机房部署

二. 热点事件的高可用

热点事件评论业务特性：

1.写评论会比较多，并发量比较高

2.看评论和看微博类似，并发量会比较高，不太好估算

架构设计思想：做好预防

架构设计：

写评论考虑几十万已经是极限，采用队列存储，使用写缓存，异步写，慢慢处理，不能丢弃

看评论涉及到热点问题，和看微博一样，采用多副本缓存，避免热点问题