微信朋友圈：应对春节千亿访问量背后的故事

腾讯云开发者

于 2017-12-05 17:23:30 发布

阅读量1.2k

点赞数 1

分类专栏：存储文章标签：微信访问量存储图片视频

本文链接：https://blog.csdn.net/QcloudCommunity/article/details/78722610

版权

存储专栏收录该内容

7 篇文章 0 订阅

订阅专栏

欢迎大家前往腾讯云社区，获取更多腾讯海量技术实践干货哦~

作者：腾讯技术工程官方号

微信朋友圈包括图片和视频两套业务架构组成，朋友圈图片的特点是请求量大、消耗计算资源较多，视频则主要消耗带宽。朋友圈的数据是永远存储的，而且随着业务的快速发展，存储容量、带宽和设备的消耗大量增加，而重大节日带来的使用量增长，更加剧了消耗，也给运维人员的保障带来了巨大压力。

节日保障主要由三方面组成：软件保障指通过程序、业务逻辑层面的优化和评估，减轻负载；硬件保障主要指带宽、机器负载的评估和扩容；柔性措施指的是通过业务调整，降低一些不重要特性的资源，来保障重点特性的正常运行。

软件保障

朋友圈整体情况：

朋友圈的架构，主要分为OC和IDC两种，IDC指的是数据中心，即数据最终落地存储的地方，OC指的是带外网的独立机房，SOC指规模较大的OC。每个IDC都有一整套接口机/逻辑设备/存储设备用以支撑用户的上传下载、及文件落地存储的需求。

OC点的主要作用是提供外网访问，承载用户的下载流量。每个OC内的设备，一起组成一个缓存池，用户下载时，本地OC中缓存不命中，才到IDC去回源拉取文件。每个OC的功能都是相同的，用户一般到就近的OC点下载，当单个OC点故障时，会通过重试或者切换让用户到其他OC点下载，确保下载成功。

容灾及重试机制：

朋友圈的模块容灾主要是实现单机故障时的自动剔除，主要形式是通过master管理服务器的ip列表，通过心跳探测等方式找到异常设备，并屏蔽故障ip，不返回给前端使用，以front层的单机剔除为例：

如果整个OC或IDC点碰到故障，由于变动较大，一般依赖运维人员手工切换来恢复，或者通过模块之间的重试机制来保障

朋友圈下载的重试：

不管是用户到OC的下载过程，还是OC到IDC的回源过程，默认都会进行2次失败后的重试，并且重试一定会选择异地的接入点，避免继续重试到故障的节点。实现的原理是每一层master都会返回给前端至少两组ip列表，并保证两组ip列表为异地节点，前端失败时才可以实现异地重试。

但重试由于会造成请求的增加，所以是把双刃剑，节日期间由于请求本身涨幅已经很高，重试更容易引发问题，需要进行调整：

1.通过master路由下发，关闭重试。在元旦/春节这种请求有数倍增长的节日实行。

2.值班人员严密监控，如果IDC失败率超过20%，则紧急手工关闭重试。这种在中秋/国庆这种增长并不高的节日实行。

Front模块的重试控制界面：

硬件保障

容量评估和设备扩容：

节日前运维人员会连同资源组，根据业务预算和业务增长的需求及实际负载，进行各个机房、模块的设备扩容。预算以外的请求上涨，则通过柔性或者过载的方式，进行降低或者拒绝。

机房容量主要根据交换机带宽的上限评估
接入层设备容量主要根据CPU、内存的负载比例、网卡的流量/包量占比来评估。
存储层设备容量主要根据CPU、内存的负载比例、磁盘IO的读写次数来评估。

春节朋友圈上传负载：

业务侧春节要求的增长比例，是上传支持9倍增长，下载支持1倍增长，超过这个比例的请求可以拒绝掉，但根据预算扩容后，达到上图的效果，还是有部分模块无法支持这个涨幅，尤其是压缩compress模块，该模块每支持一倍增长就需要大量虚拟机扩容，预算内无法支持，这样就需要使用柔性策略来解决。

柔性策略

朋友圈的柔性策略分为两层：

第一层是粗暴柔性，即按比例、接业务直接限制上传下载的请求，被限制的请求会返回给用户失败，与微信C2C相同，这种一般用于超过系统预估的负载能力，造成系统故障时用于快速恢复业务时使用。

第二层是按业务特性柔性，即从业务层面通过降低图片视频清晰度、延迟用户更新等方向降低系统的负载。下面主要详述业务柔性

朋友圈业务的主要增长与瓶颈：

从前文的设备负载评估图看，在预算范围内，接入层和逻辑层都只能支撑5倍增长，而压缩compress模块只能支撑1倍增长。

1.压缩compress柔性

Compress模块的作用是将客户端上传来的原始图片按需求压缩成各种格式和尺寸，以支持特定的业务场景，并且节省存储空间和带宽。由于压缩技术的不断发展，使用更先进的压缩格式，同等清晰度的图片压缩比例越高，需要消耗的压缩计算资源就越多。

所以如果反向操作，将当前使用的hevc格式替换回jpeg格式存储的话，就可以节省压缩资源，实测compress的cpu负载可以降为20%，即支持5倍增长。但图片的平均大小也会上涨，造成下载流量上涨。

所以采用的折衷方法，是在上传图片换回jpeg格式的同时，将图片的清晰度从70降为50，这样可以减小文件平均大小，从而抵消换回jpeg格式带来的流量上涨效果。实际测试中，发现用户对降清晰度的感知并不明显，在节假日短暂开启不会影响用户体验。

2.小视频码率柔性

小视频的带宽平时会超过1TB，节日效应增长明显。所采取的降流量方法与图片类似，即降低上传视频的码率，通过降低文件平均大小的方法来节省带宽。

柔性：小视频码率1800 -> 1200 平均大小 2.1MB -> 1.3MB

经测试，降码率后基本不会影响用户体验，但由于是对新上传视频生效，要体现到下载带宽的下降中，就有相当程度的延迟，大约需要4小时完全生效。所以这一柔性措施在节日之前就需要开启，不能用于应付紧急情况。

降码率生效期间流量变化

3.上传TSSD缓冲池柔性

由于上传preupload接口机及后层的逻辑模块等，都无法支持10倍涨幅。所以在架构中另外搭建了两套TSSD缓冲池，缓冲池用于临时存储新上传的文件，可以支持读写。按上图所示，在zone模块处增加了缓冲池一，在上传preupload处，增加了缓冲池二。两个缓冲池的作用是有区别的：

zone模块如果过载，主动过载掉的上传请求，不会直接返回失败，而是将请求写入到缓冲池一中，缓冲池一中的文件并不能被下载到，但会按比较慢的速度将文件下发，写入到后端模块。所以缓冲池一的主要作用是减缓短时间内大量的上传请求，而不是完全抵消上传请求，并且缓冲池一中的文件是不能被下载到的。

在preupload模块处增加了缓冲池二，preupload模块中对存储TFS的写请求次数做了限制，如果上传请求数超过了存储TFS的能力，则preupload会将请求写入缓冲池二。用户下载时，会根据文件标识进行判断，如果发现文件存储在缓冲池二而不是TFS中，则会到缓冲池二中去获取文件。所以缓冲池二可以替代TFS的功能，起到保护底层模块的效果。等到缓冲池二下架时，需要将其中的文件人工写入到TFS中。