模块五作业 - 微博评论 - 高性能高可用架构
一、计算性能预估
1. 用户量预估
用户量:
2020.9 月月活 5.11 亿,日活 2.24 亿。
关键行为:
发微博
看微博
评论微博
注:本次作业只设计评论微博部分。
2. 用户行为建模
评论微博
微博评论一般是基于某一条微博下面进行评论,转发的微博我们认为是另一条微博,在转发的微博下评论我们不认为是在同一条微博下评论,但整体的评论的写入 TPS 需要考虑进去。
微博每天发 2.5 亿条,大 V 或者明细的一条微博可能评论几十万甚至上百万,普通人的微博可能就几条甚至没有。
看评论
看评论与发评论的时间段是基本重合的
3. 性能需求计算
评论微博
我们预估一个大概的平均值,假设一条微博平均评论条数 10 条,而且评论的时间范围一般与阅读微博的时间基本重合,也就是 8:00~9:00、12:00~13:00、20:00~22:00 这四个小时,那么评论微博的 TPS 计算如下:
25 亿 * 60% / (4*3600) ≈ 100k/s
看评论
按看微博的 QPS≈1000k/s,那认为每条微博的评论 10 条的话,那么看评论的 QPS 我们认为是
1000k/s * 10 = 10000k/s
二、高性能架构设计
1. 评论微博
业务特性分析
微博评论是一个写操作,不能用缓存,但是我们可以用缓冲(Buffer),因为用户发出去的微博可以不被立刻刷新出来,因为本身涉及一个内容审核,可以提示审核通过后会更新出来,让用户有一个感知。
架构分析
用户量过亿,应该要用多级负载均衡架构,覆盖 DNS->F5->Nginx->网关的多级负载均衡。
架构设计
负载均衡算法算作
微博评论依赖登录状态,登录状态一般都是保存在分布式缓存中的,因此微博评论将请求发送给任意服务器都可以,这里选择“轮询”或者“随机”算法。
业务服务器数量估算
微博评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统),因此按照一个服务每秒处理 500 来估算,完成 100kTPS,需要 200 台服务器,加上一定的预留量,需要 250 台服务器。
2.看评论
业务特性分析
看评论是一个典型的读场景,由于微博评论发了后不可以改,可以使用多级缓存架构与多级负载均衡架构。
架构分析
评论量过亿,应该用多级负载均衡架构,覆盖 DNS->F5->Nginx->网关的多级负载均衡。
QPS=10000k/s,应该使用多级缓存架构,同时因为评论发了之后不能改,所以使用 CDN 缓存是缓存设计的核心,预计拦截>90%以上请求。
由于时间局部性,可以使用进程内缓存提高读评论系统处理能力。
架构设计
负载均衡算法算作
看评论是一个无状态的读操作,直接使用“轮询”或者“随机”算法,请求发送到任意服务器即可。
业务服务器数量估算
假设 CDN 能承载 90%流量,那么剩下的 10%读评论进入系统,则请求 QPS=1000k/s,如果读评论的的大部分请求都能由多级缓存承接,那么假设单台业务服务器的处理能力是 1000QPS,则服务器数量为 1000 台,按照 20%的预留量,需要 1200 台服务器。
3.多级负载均衡架构
4.多级缓存架构
5.整体架构设计
微博业务
任务分配
双机房/三机房:亿级请求,考虑到机房容灾,宽带限额等,需要分配请求到不同的机房。
任务分解
因为微博评论与看评论有时间跨度可能会相隔几小时甚至几天及以上,并且由于读与写的请求性能相差比较大,读请求需要更多的缓存设计,所以将微博评论与看评论分拆到不同的服务,提升系统整体的性能跟可用性。
三、热点事件高可用计算架构设计
1. 用户行为建模与性能估算
背景
热点事件指某个大 V 或者明星爆料或者官宣,虽然只有一两条微博,但引起大量用户在短时间内访问,给系统造成很大压力。
评论微博
用户会在某条微博下进行大量评论,比如某明星一条微博下就能有几十万上百万的评论,并且是在当前微博最火的时候,假设 10%的用户会在事件发生后 60 分钟内评论。
大部分的评论应该还是落在最初的那条微博下面
用户的评论可以异步写入,但是不能丢失。
看评论
大部分的读请求应该还是落在最初的那条微博的评论里。
量级很难预估,与事件影响力和影响范围有关。
2.架构设计
1. 微博评论
由于写评论不可以丢失,但是可以异步,那么可以考虑分布式消息队列的方式,比如 rabbitMQ 等。
2. 看评论
热点事件的微博评论存在缓存热点问题,可以考虑“多副本缓存”。
3. 架构设计
版权声明: 本文为 InfoQ 作者【babos】的原创文章。
原文链接:【http://xie.infoq.cn/article/8011332e14190f00a99568805】。未经作者许可,禁止转载。
评论