架构实战营 - 模块 5- 作业
1. 概述
设计微博系统中”微博评论“的高性能高可用计算架构。
2. 用户行为建模和性能估算
2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）
假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条
大部分的人（60%）发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00
假设平均每条微博被评论 10 次，则评论微博次数为：2.5 亿 * 10 = 25 亿
评论微博时间分布与发微博基本重合，因此微博评论的 TPS 为：25 亿 * 60% / (4*3600) = 100K/s
假设平均每条评论被观看 10 次，因此微博评论的 QPS 为：25 亿 * 10 * 60% / (4*3600) = 1000K/s
3. 非热点事件高性能计算架构设计
针对非热点事件，微博评论的核心功能分为发评论与看评论两个部分。
3.1 发评论
3.1.1 业务特性分析
发评论重要性不如发微博本身，评论发出后不需要其他用户第一时间就能看到，所以可以采用本地缓存+写缓冲的方式进行缓存处理
3.1.2 架构分析
用户量过亿、TPS 高达 100K，需要使用多级负载均衡架构（DNS->F5->LVS->Nginx->网关）
本地缓存基于客户端本地缓存实现，写缓冲基于服务端 SSD 缓存实现（基于 SSD 实现 Buffer 队列）
3.1.3 架构设计
1. 负载均衡算法选择
与发微博业务类似，写评论所依赖的登录状态一般都是保存在分布式缓存中，因此将请求发送给任意服务器都可以，选择“轮询”或者“随机”算法
2. 业务服务器数量估算
与发微博类似，写评论依赖审核系统、存储系统和缓存系统，由于添加了服务端 SSD 缓存，每个服务器处理能力比发微博高，按照一个服务器（32 核）每秒处理 800 来估算，完成 100K/s 的 TPS，需要 125 台服务器，加上 20%预留量， 预计需要 150 台服务器
3.2 看评论
3.2.1 业务特性分析
与看微博类似，看评论也是典型的读场景，且 QPS 高，需要使用缓存架构及负载均衡架构。
3.2.2 架构分析
用户量过亿，需要使用多级负载均衡架构（DNS->F5->LVS->Nginx->网关）
QPS 高达 1000K，需要使用多级缓存架构，且需要使用 CDN
3.2.3 架构设计
1. 负载均衡算法选择
与看微博业务类似，将请求发送给任意服务器都可以，选择“轮询”或者“随机”算法
2. 业务服务器数量估算
假设 CDN 能够承载 90%的用户流量，则实际进入系统的请求 QPS 为 1000K/s * 10% = 100K/s。读评论业务逻辑较为简单，单个服务器（32 核）处理能力按照每秒 1000 估算，处理 100K/s 的 QPS，需要 100 台服务器，加上 20%预留量， 预计需要 120 台服务器
3.3 整体架构设计
整合微博评论发与看两类核心功能，针对非热点事件，整体计算架构设计分析如下：
任务分配：基于负载均衡架构，采用多机房部署
任务分解：发评论与看评论的量级差异不大，因此不用将发评论与看评论拆分为不同的服务，使用统一的微博评论服务即可
负载均衡算法：采用随机或轮询算法即可
服务器资源估算：因为读和写公用一个服务，所以单个服务器的整体处理能力要整体低于前文的估算值，这里预估单台服务器（32 核）处理能力为每秒 500，处理 100K 的 TPS+QPS 需要的服务器数量为 200 台，加上 20%的预留量，需要的服务器数量为 240 台
结合上述分析，微博评论整体负载均衡架构如下图所示：
缓存架构如下图所示：
4. 热点事件高可用架构设计
4.1 业务特性分析
写评论：热点事件一般伴随着大量的写评论，但是评论的重要性和影响力不如原微博本身，且评论的实时性要求不高，其他用户不一定要第一时间看到
看评论：热点事件所对应评论的查看请求也会大幅提升，尤其是一些“神回复”
4.2 架构设计分析
由于热点事件的不可预估性，针对微博评论的架构设计依然遵循提前做好预防的核心思想。结合上述业务特性分析，整理架构设计要点如下：
写评论：考虑到写评论的重要性较低、实时性要求不高，可采用排队+限流的方式进行保护，排队主要通过写缓冲实现，缓冲队列大小限制为 10 万；而限流方面，与转发微博类似，可采用漏桶算法尽可能减少评论丢失
读评论：与读热点微博类似，结合看评论的应用内缓存设计，可对评论进行多副本缓存。考虑到“神回复”的阅读量一般远高于其他评论，可设置评论阅读量阈值，根据不同等级的阅读量复制多份评论缓存到不同的缓存节点
还未添加个人签名 2017.12.17 加入
还未添加个人简介
评论