写点什么

架构实战营作业 M05

用户头像
Shawn Liu
关注
发布于: 2 小时前

性能估算

【微博评论】

由于绝大部分微博用户看微博的对象是大 V 和明星,因此我们假设平均一条微博观看人数有 100 次,其中又平均有 10 人会进行评论(包括评论互动)。则评论微博的次数为:

2.5 亿 * 10 = 25 亿


大部分人评论微博的时间段和发微博的时间段基本重合,因此评论微博的平均 QPS 计算如下:

25 亿 * 60 / (4 * 3600) = 100K/s


PS. 我觉得我评论的比例估的有点高,但是个人觉得微博评论是体现平台用户活跃度很好的一个指标。所以我觉得在资源预估上适当放肆一些比较好。


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

【业务特性分析】

评论微博同样是一个典型的写操作,但是和发微博不同,用户发完评论并不需要立即查看对应评论。所以可以使用消息队列 + 负载均衡。


【架构分析】评论微博也是核心功能,因为整体量级、所需要的架构组件栈也和发微博、看微博的要求级别不太一致,所以还是推荐进行服务拆分。而且因为发微博、看微博的意见使用了全链路的负载均衡,所以复用现有技术栈即可(覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡),直接在服务器集群中进行服务器的区分,网关集群以上的负载均衡直接复用。


【架构设计】

评论微博和发微博一样,也涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖缓存)、数据写入缓冲(依赖消息队列)。但是因为评论微博时效性并没有发微博这么高,每个服务可以先写到消息队列,然后再异步刷到存储系统。评论数据写 MQ 单个服务处理按 1W/s 的 TPS 计算,需要 10 台服务器。MQ 同步到存储,同样按每个服务每秒处理 500 来估算,完成 100K/s 的 TPS,需要 200 台服务器,因为使用了 MQ 当做缓冲,且评论时效性要求并没有那么高,可以预留 5 台写 MQ 机器,10 台同步存储服务器。一共 215 台差不多。


热点事件时高可用计算架构设计

热点事件指某个大 V 或者明星爆料或者官宣,虽然只有一两条微博,但引起大量用户在短时间内访问,给系统造成很大压力。


【架构设计分析】

相对于转发微博,当某个热点事件发生时,当前微博评论应该是“主战场”。所以设计可以参考转发微博,但是指标要求需要高于转发微博。

高可用架构示意图:



发布于: 2 小时前阅读数: 2
用户头像

Shawn Liu

关注

还未添加个人签名 2018.05.04 加入

还未添加个人简介

评论

发布
暂无评论
架构实战营作业 M05