模块五：微博评论模块高性能高可用计算架构设计

作业描述：

设计微博系统中“微博评论”的高性能高可用计算架构。

【作业要求】

基于模块五第６课的微博实战安利，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于一下内容：

１.　计算性能预估（不要考虑存储性能）

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

３.　热点事件的高可用计算架构。

业务背景：

微博是一个提供微博客的社交媒体网站，一个基于用户关系的信息分享，传播以及获取信息的平台。用户可以通过网页，wap 页面，手机移动程序等发布动态，并可上传图偏和视频或视频直播，实现即时分享。传播互动。

微博评论功能是微博业务的核心功能之一，用户可以对其可见的微博内容进行评论， 评论发表后该微博的其他可见用户将会看到该评论。

性能分析：

根据新浪发布的 2020 年微博用户发展报告。微博 日活用户为 2.24 亿，月活用户为 5.11 亿。互动量峰值发生在午时（12：00）和亥时（22：00）

延用课程 6 中业务假设：

1.考虑到微博是一个看的多发得少的业务，假设平均每天每人发 1 条微博（只考虑文字）， 则微博每天的发送量约为 2.5 亿条。

2.大部分人发微博的时间集中在早上 8：00-9：00， 中午 12：00-13：00， 晚上 20：00-22：00， 假设这几个时间段发微博总量占比为 60%, 这 4 小时的平均发微博的 TPS 计算如下：

2.5 亿*60%/(4*36000) 约 10k/s.

再此基础上，我们假设每条微博的平均评论数为 10 条，则微博评论 TPS 约

100k/s

架构设计：

根据微博的业务特性，微博中用户的关注关系是单向关系，存在大 V 效应。如果是单向，信息扩散的时效性可以适当降低一些。相反如果是双向，即好友关系，好友数量有限，不会产生大 V，因为每个人的精力有限，他不可能主动加千万好友，这时候关系更精密，对时效性要求就会高一些。

我们将微博业务简单的拆解为，读微博， 写微博 与 评论三部分。评论也可以认为是读评论，写评论并归入读微博， 写微博业务中去。但考虑到业务的重要程度，当灾难及异常发生时，微博的读写是核心保障业务，而评论业务相对来说故障容忍度及延迟容忍度都较高，同时评论的读取流量也远小于微博的读取流量，因此我们将评论的读写单独拆分为一个微博评论服务。

同时，微博流量热点分布呈现不均匀的现象。当有热点事件产生时，流量集中在数据热点上，据此我们的架构将针对热点事件时，和非热点时间时分别讨论。

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

• 后端评论服务无状态，上层负载均衡采用简单轮询算法即可。

• 评论服务依赖分布式缓存系统，此处分布式缓存系统有两种用途 a.记录用户登录状态 b. 缓存热点访问数据。

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

热点事件场景下，考虑引入漏桶算法，漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.