微博评论缓存架构设计

[看微博评论]

由于绝大多数微博评论都是由用户来进行评论的,明星和大 V 很多评论微博内容,因此我们假设平均一条微博评论有 100 人来浏览,由观看微博评论的次数为:

2.5 亿 * 100 = 250 亿

绝大部分人看微博评论的时间和写微博评论的时间基本上是重合的,因此看微博评论的平均 QPS 如下:

250 亿 * 60% / ( 4 * 3600) = 1000K/s

[业务特征分析]

写微博评论本质上就是一个写操作,因此不能采用缓存,可以使用负载均衡

[架构分析]

首先,需要写微博评论的用户量过亿,在该系统中采用多级负载均衡的架构,覆盖 DNS->F5->Nginx->网关的多级负载均衡

[架构设计]

1.首先选择负载均衡算法

首先,写微博评论时需要依赖于当前用户保持登录的状态,登录的状态一般都是保存在分布式缓存中的(尤其是微博这种系统),因此在写微博评论的时候将写微博

的请求发给任意的服务器都可以.因此这里选择"轮询"或者"随机"的算法

2

2.业务服务器数量的估算

写微博评论涉及几个关键的处理:写内容审核(需要审核系统), 数据写入存储(需要存储系统), 数据写入缓存(需要缓存系统,需要将缓存中的内容写入后台数据

库).因此这里假设每一个服务每秒处理 500 来估算,完成 10K/s 的 TPS,需要准备 20 台服务器, 加上一定的预留量, 30 台服务器基本上就差不多了.

那么,关于看微博评论的负载均衡架构显示如下:

关于写微博评论的负载均衡架构显示如下:

接下来,微博评论的整体多级缓存架构如下:

如果遇到热点微博评论,如果存在大量评论该微博或者转发该微博,这里假设在 10%的用户在 1 个小时内转发或者评论该微博,就会对该系统造成很大的压力

[业务特点分析]

写热点微博评论与通常写微博是一样的,但是不同在于同一时间内会有大量的写微博的请求

如上所述,既然无法预估写热点微博的规模大小,不如就事先做好此类事件的预防工作

[架构设计分析]

1.写热点微博

可以考虑大量写微博的请求进行"限流",由于热点事件往往会带来更好的微博的宣传效应,因此尽量少放弃或者丢弃此类写请求,考虑采取"漏斗算法"

2.看热点微博

很明显,热点微博同一时间会有大量的用户进行围观,但已采用的缓存架构采用了应用内缓存.所以从总体上来看,缓存热点问题不一定很明显.

关于热点微博的总体架构如下：