模块 5- 课后作业

1、微博评论性能估算

【用户量】

月活 5.1 亿，日活 2.24 亿

【用户关键行为】

• 发表评论

• 浏览评论

【性能预估】

• 发表评论

  一条微博发布后，一般浏览的人数要远远大于评论的人数，所以我们按照浏览总量的 0.5%~1%来计算评论数量，为留余量先按照 1%来计算。则微博每天评论数为(2.5 亿×100)×1% = 2.5 亿条评论。

  发表评论的时间基本与看微博时间吻合，所以微博评论的 TPS 计算如下：

  2.5 亿×60%/（4×3600）= 10 K/s ,约每秒 1 万的写入请求。

  
  

• 浏览评论

  由于绝大部分人只浏览每条微博下一些热门评论，我们假设一条评论被浏览 50 次，则总的评论浏览次数为 2.5 亿×50 = 125 亿。

  浏览评论的时间基本与看微博时间吻合，所以浏览评论的 QPS 计算如下：

  125 亿 × 60%/（4×3600）= 500 K/s,约每秒 50 万的查询请求。

2、非热点事件的高性能计算架构，需要考虑是否拆分独立服务

微博评论

【业务特性】

微博评论也是一个典型的写操作，不可以使用缓存，可以使用负载均衡来支持高并发写入。同时微博评论支持写缓冲，由于评论及时性要求不高，可以先写入缓冲队列，再批量写入存储。

【架构分析】

用户量过亿，且峰值 QPS 为 50 万，需要多级缓存（http 缓存+cdn 缓存+ng 缓存+本地缓存+分布式缓存）。

【架构设计】

1、负载均衡算法

微博评论依赖登录，登录状态保存在 cookie 或分布式缓存中，服务器本身无状态，因此发给集群中任意一台机器即可，一般采用轮训或者随机，也可以根据机器配置情况，采用加权轮询算法。

2、是否独立及服务器估算

微博评论与浏览业务请求量比较庞大且为了在高峰期不干扰发微博与浏览微博核心业务或者一些特殊情况下需要关闭评论减少影响，因此需要拆分独立的服务，保证服务性能。

发布评论包含几个步骤：内容审核、数据写缓冲、数据写存储、数据写缓存，由于写评论可以使用写缓冲，所以每台机器可以承载更多的并发写入请求，按照一个服务器每秒处理 800 个估算，完成 10K/s 的评论写入，大概需要 13 台服务器，加上一些预留量，大概 16 台左右。

评论浏览

【业务特性】

评论浏览属于读操作，可以把热点评论，写入缓存，提高读取效率。

【架构分析】

TPS 为 1 万多层负载（DNS+F5+NG+网关）做高并发支撑。

【架构设计】

1、负载均衡算法

浏览评论请求发给任意服务器即可，因此可采用轮训或者随机算法，也可以根据机器配置情况，采用加权轮询算法。

2、业务服务器数量估算

使用 CDN 缓存可以承载 90%用户请求，500K × 10% = 50K/s,读取请求逻辑较为简单，按照一台业务服务提供 2000/s 的读写能力，再按照一定的预留量，大概需要 30 台服务器即可。

3、热点事件的高可用架构

微博评论

1、热点事件发生后，会有大量评论在段时间内写入，可以使用漏桶算法，将评论写请求放入队列，异步写入存储，避免流量洪峰给数据库带来的压力。

2、当突发热点事件，看微博和发微博（转发微博）等核心业务请求量较大时，可以对微博评论和浏览进行熔断降级，暂时关闭评论等非核心业务。

微博浏览

1、对于评论浏览来说，可以进行限流，如滑动时间窗口，当达到一定阈值对读请求进行限流，丢弃一部分请求，保证系统稳定。

2、可以借助 k8s 进行云部署，当遇到热点事件并发量激增时，借助 k8s 弹性扩容服务器，提供更多的算力支持。