转载

新浪微博中的周期性爆发流量

【编者按】《博文共赏》是InfoQ中文站新推出的一个专栏，精选来自国内外技术社区和个人博客上的技术文章，让更多的读者朋友受益，本栏目转载的内容都经过原作者授权。文章推荐可以发送邮件到editors@cn.infoq.com。

业务背景

最近，微博平台的群发业务增长迅速，一个月内业务量暴涨70%，出现两次负载过高报警，通过紧急扩容解决。仔细思索，这一类业务场景在移动互联网中非常普遍，值得深入探讨。

在微博通讯系统中，有两种常见的模式，一种是单点对单点的私信通讯方式，另一种是单点对多点的群发通讯方式，后面一种主要使用在粉丝服务平台。最近几年，通讯内容趋向于富媒体，包含图片、网络文章、音视频文件等，微博统一将各类资源抽象为卡片（Card），平台负责Card数据的存储与处理，前端和客户端根据不同的模板渲染Card。

微博服务号基本都是每天早上向所有粉丝推送一条消息，这就是群发场景，同一时段高并发的请求访问给后端系统带来巨大压力。

问题挑战

对于群发业务，增加缓存能挡住大多数的流量，但这里还有诸多挑战：

缓存大小规划，如果所有内容都缓存，成本直线上升，虽然可以抗住峰值时段流量，但是非峰值时端，资源严重浪费。
缓存资源有状态，很多Card并非完全是静态资源，根据请求参数不同返回数据不同。
同一资源集中访问间隔时间非常短，经常维持在几分钟内，还有一个特点，5%的资源占据了80%以上的访问请求。

弹性计算or CDN？

问题一：能否使用云服务中的弹性计算解决 ?

如果业务爆发周期为一年中的某一季节或者某些节日，弹性计算可以较好地解决这个问题，如果业务爆发周期为一天中的某一时段，从运维管理层面来讲，弹性计算可实施性非常低。

问题二：能否使用 CDN 技术缓存 Card 资源？

Card资源为后台动态生成，有些Card是无状态的，有些是有状态的，CDN网络可以处理无状态的Card资源，对于有状态的，目前还没有成熟的CDN解决方案，同时Card资源的使用方式也与传统的CDN资源使用方式不太相同。

技术方案

针对这种每天粒度周期性爆发的业务模型，团队总结出三种技术方案。

方案一：针对业务的定制化方案

这种方案分析业务特点，提出解决方案，不具有通用性，目前平台的Card服务使用方包含各个端的Feed组以及通信系统，而周期性爆发流量，目前仅有通讯系统中的群发和群聊会产生，针对这种情况，Card Service改进点：

区分有状态和无状态的Card请求，有状态的不缓存。
无状态的Card请求，结合业务特点，判断是否是群发以及群聊业务。
对于群发和群聊业务，将Card资源缓存在分布式缓存中。

分布式缓存有一个问题，虽然可以按照服务号水平分区在不同的节点，克服缓存容量问题，但是不能处理瞬时的千万级流量高峰，这种情况需要在每台前端机上做本地缓存，大小受前端机内存大小限制，我们根据业务特点进一步做优化, 对于群发和群聊业务，使用L1本地缓存和L2分布式缓存。

L1本地缓存处理服务号粉丝规模超过20万的，通过众多的前端处理机L1缓存抗峰值。
L2分布式缓存处理粉丝规模较小的服务号，处理从L1缓存穿透过来的访问。

方案二：简单的数据挖掘策略

通用方案基于实时的流量统计分析，运用数据挖掘算法，统计出资源请求中最频繁的K个，同时本地缓存大小不能太大，计算性能要求也较高，方案二将高频资源请求检测模块放在前端机本地缓存，使用类蓄水池采样算法，适合微博的群发场景。

这里介绍一下蓄水池问题：在不知道文件总行数的情况下，如何从文件中随机的抽取一行？

首先想到的是我们做过类似的题目吗?当然，在知道文件行数的情况下，我们可以很容易的用C运行库的rand函数随机的获得一个行数，从而随机的取出一行，但是，当前的情况是不知道行数，这样如何求呢？我们需要一个概念来帮助我们做出猜想，来使得对每一行取出的概率相等，也即随机。

有了这个概念，我们便有了这样一个解决方案：定义取出的行号为choice，第一次直接以第一行作为取出行 choice ，而后第二次以二分之一概率决定是否用第二行替换 choice ，第三次以三分之一的概率决定是否以第三行替换 choice ……，以此类推。这种方法的巧妙之处在于成功构造出一种方式，使得最后可以证明对每一行的取出概率都相等。

微博业务场景中的问题为长度为 K 的蓄水池，当 Card 资源没有命中缓存时，资源以 K/N 的概率存储到缓存，其中 K 为蓄水池的长度， N 为时间片内的平均访问量。

方案三:基于Spark集群的Top K资源请求

这是方案二的升级版，将高频资源请求检测模块从本地缓存迁移到Spark集群，通过其强大的数据处理能力，更精确更实时地统计Top K高频资源访问。

目前，工程领域已经涌现众多性能优越的Top K算法，有基于计数的Sticky Sampling算法，也有空间使用率很低的Space Saving算法（思路和蓄水池有一点像，都是概率替换），还有使用Bloom Filter数据结构的算法，这些算法作用于Spark集群，理论上效果比方案二更好，但是消耗的资源更多。

总之，文中的三种方案没有好坏之分，应该结合公司业务特点，选择最适合的。

本文首发于“微博平台架构”微信公众号，发布时有少量的文字润色和调整。