看腾讯运维应对“18 岁照片全民怀旧”事件的方案，你一定不后悔！

[TencentCOC]

作者丨魏旸：腾讯高级工程师，15 年运维经验的老专家，负责 QQ 空间、微云、QQ 空间相册的运维工作，亲历 8 亿军装照、QQ 空间异地多活建设等重大架构升级事件。

2017 年 12 月 30 日，元旦假期的第一天，你的朋友圈被 18 岁照片刷屏了吗？据说“晒 18 岁照片”的根源是 2017 年年未，最后一批 90 后将度过他们的 18 岁生日。这意味着，90 后已全部成年，集体告别了青葱芳华。

这是一个青春的、也是怀旧的年华，QQ 空间做为国内第一批社交平台产品，承载了较多的用户记忆，大量的用户涌入 QQ 空间翻找自己多年前的 18 岁照片晒上社交平台。集体引爆了空间相册山洪峰涌而至的照片流量。

下面这篇文章让我们回顾 12 月 30 日，空间相册面对突发四倍流量，七成访问落在后端冷存储的极端压力下，相册运维、开发团队如何凭借平时基础功底，从告警、容量、扩容、柔性、调度等全方面运维能力，扛过“ 18 岁照片”的全民怀旧事件。

业务数据回顾

突然来袭的用户集中行为，给我们平台的能力带来了非常严峻的考验，先让我们先来看一组数据：

1 ） 图片下载量峰值达到平日晚高峰的 4 倍，且 70%以上都聚集在平日不怎么访问的冷图片。

2 ） 图片上传量达到平日晚高峰的 4 倍。

3 ） 带图说说峰值达到平日晚高峰的 12 倍。

业务架构剖析

面对突然涌入的用户请求，相册开发与和运维是如何坚守阵地，度过这次难关的呢？

在介绍一系列的措施之前，首先不得不介绍下相册业务架构，下图较为抽像地介绍了相册的主要架构：

1. 上传链路： 用户上传图片 /视频，数据流主要由上图中间链路处理，经过 proxy->逻辑（分片、权限、缓存等）->存储接入（分片整合、生成文件地址等）->落地存储
2. 下载链路：

• 用户通过空间（说说、日志、动态等）访问相册图片，图片适配模块根据用户请求、终端、请求量等场景适配出最优图片规格，返回用户图片、视频 URL。
• 用户通过上一步获取的 URL 访问后端存储的图片、视频。

日常运维工作

同时，我们介绍一下腾讯 SNG 社交网络运营部平时进行的一些日常容量管理工作。

1 ） 链路梳理

如上节所述，我们梳理出相册核心链路，常用梳理过程有几种：

• 通过抓包形式确定链路模块
• 通过设备上报的主被调数据确定调用链路
• 名字服务中获取相关的调用链数据。
• 通过全链路数据汇总出相关的链路。

2 ）压测：

定期对整条链路做压测，压测手段有异地调度压测，或单机压测，通过压测找出链路内存在瓶颈的模块，及时修正链路模型。

3 ）高低负载处理：

依据压测容量数据，分配设备扩容。负载较低的模块设备进行缩容下线以节省成本。

容量应急措施

但是这里的问题是显而易见的：以上常规性的工作，只能发现常规场景下内部存在的瓶颈。像 18 岁照片这种特殊场景（用户大量读取空间相册，获取冷数据），无法通过常规压测检测出来问题, 这就需要一系列的机制来解决

1) 监控和容量弹性机制：

通过 IaaS 层监控对系统的基础特征进行监控，（如 CPU 负载，出入流量），当模块容量出现异常时，弹性扩容机制需要介入处理，进行扩容。

如何快速支持短时间扩容上千台设备呢？不得不介绍一下腾讯 SNG 的织云运维理念。

如上文所述，我们的设备被分配到不同的“业务模块”，而每一个模块有如下的属性：

1 ） 包：业务处理逻辑文件包，包含业务包与基础包。

2 ） 配置：包含业务包要使用到的各种配置

3 ） 权限：包含支撑业务包正常运行时需要的数据库、内部鉴权系统等权限

4 ） 测试工具：包含业务包启动后，能否接入现网的测试标准

织云提倡的自动化理念是：标准化 -> 配置化 -> 自动化，让企业的常用操作固化成流程工具。不依赖容易过期的文档，不依赖容易流失的人的经验。

参考持续交付的原则“为软件的发布创建一个可重复且可靠的过程”，运维团队为了解决人肉操作经验差异的难题，将运维操作通过流程 DIY 编排能力，实现标准操作的固化。“ 18 岁照片”活动扩容，任何一个运维人员只需要执行 QQ 相册的扩容功能即可实现容量扩展，而织云流程会自动化的完成整个服务部署和上线的操作。（如下图）

柔性业务架构

前面我们说过，相册在当天的峰值下载量涨了 4 倍，且多是访问冷数据，但在短时间内无法筹集到 4 倍的资源，业务是如何应对的呢，在保证用户核心体验不受影响的前提下，我们采用了一些柔性手段。

回顾一下，当时我们在容量不足时碰到以下的问题，导致短时间内部分图片拉取耗时过长，影响用户体验。

1 ） 存储压力过大。

2 ） 自身模块压力过大。

针对存储压力过大的问题，我们采用了以下几个手段来降低业务负载：

1 ） 存储手段

a. 图片适配优化索引策略减少存储压力

减少拉取照片分批次数，降低后端存储处理压力。分批拉取照片列表数量增加 3 倍。交互次数直接下降近 2/3。

b. 图片上传增加本地缓存空间减少存储高负载造成的用户上传失败

调整上传逻辑模块，从原来的本地内存缓存优化为内存+本地磁盘缓存，通过增加本地缓存空间减少后端存储高负载对用户侧上传图片 /视频的影响。虽然底层存储高负载了，但是用户还是可以不受底层影响，将图片通过接入上传到逻辑层缓存。存储压力释放后即可将逻辑层缓存的数据上传到存储层。

c. 降低图片规则，减少图片下载流量：

一张图片分为小、中、大三种规格，为了节约存储容量中图是通过图片压缩模块实时压缩返回给用户的，小图和大图真实存储在存储模块。为了降低图片下载的流量压力，我们调整了适配策略，用户访问大图，适配直接返回小图的 url，减少了图片压缩逻辑，并且降低了带宽。调整后图片下载带宽对比如下：

d. 上传不检查相册有效性，减少存储索引访问量：

正常情况，在用户上传图片时到相册时，会检查相册是否存在，如相册已被删除，则直接报错。柔性策略跳过相册有效性检查，直接上传图片到后端存储，降低索引访问量，降低索引模块负载。

同时在业务逻辑上，也做了以下的柔性措施：

a. 核心模块启用过载保护机制：

判断单机 cpu 使用率超过 80%时，会自动丢弃多余的请求，以保证业务逻辑模块在大量用户请求场景下不雪崩。

b. 柔性关闭非核心业务功能减少业务自身负载

每张图片在高速存储会存储一份位置信息，图片裁剪时用于标示一张图片核心元素的位置。禁用此逻辑后，用户看到的图片无人脸中心点, 客户端裁剪可能不准确。

关闭用户删除标记，适配图片适配前会预先检测图片是否被删除，如已被删除则不会返回对应的图片列表。删除标记逻辑也会频繁和索引模块交互，高峰期时会占用大量计算资源。禁用此逻辑，用户访问相册时会看到已被删除的图片，但是会标记为灰色已删除。

调度：相册业务分布在三地，每地分别承载了约 33%的用户，某地请求过高时，我们可以调度用户至其他容量相对较低的地域。

小结

从“ 18 岁照片全民怀旧”热点社交事件可以看到，事发过程中留给运维的时间相当少，只有严格贯彻“养兵千日用兵一时”的标准化运维理念，建设完善的运维体系，才能在突发事件中游刃有余。

后记

这次 18 岁照片活动，相册通过多种手段顶住了业务压力。 同时通过这次活动，我们也对未来的运维工具进行了进一步规划，比如：

a) 基于容量的智能调度体系

b) 资源托管平台。

c) 自动演习系统。

织云平台的运维能力在不断迭代，期待在下一次活动来临时能够做到更加有条不紊。

[zjp]

https://www.v2ex.com/go/promotions

[Tink]

可以可以，专业

[psfang]

同事，发帖能遵守下社区规则吗，注意节点。

[dong3580]

@Livid

[firefox12]

相册业务分布在三地，每地分别承载了约 33%的用户，某地请求过高时，我们可以调度用户至其他容量相对较低的地域。

但是数据是存了 3 份的？ 所以存储空间使用率至少 300%?

通篇都是开发已经设计好的灰度开关，直接使用而已。

4 倍冷数据的读取，4 倍新数据，都是在系统设计的负载之内，而且数据读取大部分应该被 CDN 就挡掉了，如果真的系统可以突然把压力提高 4 倍，那么要么你们加了 4 倍的资源，要么你们的系统利用率不到 20%。

[yanyandenuonuo]

qq 空间现在日活只有百万级？

[ctsed]

@yanyandenuonuo 怎么可能，00 后的主战场

[hanbing135]

广告？

[Livid]

提醒一下，以后这类软文请只发到 /go/promotions 节点。

[TencentCOC]

@psfang 好的..虽然是热点标题，但是内容不虚，还是蛮多干货的，就放在这个节点了。下次会注意的哈，谢谢提醒~

[TencentCOC]

@firefox12 数据没有存三份
每个地域存储当地用户上传的数据，不会同步其他地域用户上传的图片。异地访问，根据图片热度，直接 oc 加速或者回源到当地存储访问。
文章提到了，7 成用户访问的都是冷数据，会直接回源到内网机房访问。每个业务都会根据历史经验值预留 buffer 来应对请求量的增长，这里增长的倍数都是远超历史增长的。
所以我们需要在有限的资源基础上准确评估核心模块的增长，通过柔性策略来减少用户访问带给后端的压力。

[firefox12]

@TencentCOC 某地负载高，你把用户引导到其他区域，然后因为冷数据 请求会重新回源到这个负载高的地区，负载并没有减少，处理能力也没提高，这个问题就解决了？