架构 1 期模块五作业

用户量

2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）

微博评论

1）看微博的对象大多是是大 V 和明星，假设平均一条微博观看人数有 100 次，则观看微博的次数为： 2.5 亿 * 100 = 250 亿。

2）大部分的人发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发微博总量占比为 60%，大部分人看微博的时间段和发微博的时间段基本重合，因此看微博的平均 QPS 计算如下： 250 亿 * 60% / (4*3600) = 1000K/s。

3)看微博的同时会伴随评论，假设评论微博的人数为看微博的 1%，则微博评论的 QPS 为： 250 亿 * 60% / (4*3600) /100= 10K/s。

业务特性分析

 微博评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。

架构分析

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

架构设计

 1. 负载均衡算法选择

微博评论的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此微博评论的时候，将请求发送给任意服务器都可以，这 里选择“轮询”或者“随机”算法。

2. 业务服务器数量估算

微博评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因 此按照一个服务每秒处理 500 来估算，完成 10K/s 的 QPS，需要 20 台服务器，加上一定的预留量，25 台服务器差不多了。

总结

由以上数据可知，非热点事件时的高性能计算架构，不需要拆分成独立的任务，将微博评论和发微博合并为一个任务即可。

热点事件时微博评论架构设计分析

1）微博评论并非十分重要，鉴于容量无限，可以考虑限流，尽量减少丢弃，可以使用漏桶算法的写缓冲。

2）微博评论很明显，热点事件微博存在缓存热点问题，可以考虑“多副本缓存”，由于原有的缓存架构已经采用了“应用内的缓存“，总体上来看，缓存热点问题其实不一定很突出。