一直陪伴你成长的 QQ 相册后台长什么样？

作者：兰瑞

导语：QQ空间陪伴大家走过了将近12年的时光。时至今日，QQ相册已经存储了超过2万亿张图片，对比业界，可以说是当之无愧的中国第一大相册，也是世界上规模最大的图片类产品之一。本文从存储架构、容灾、加速等多方面对相册的架构进行了阐述。

[1503021352455_8910_1503021353615.jpg]

QQ空间（QZone），陪伴大家走过了将近12年的时光。其中的QQ相册，也和大家一路走来，记录下了很多中国人的成长瞬间。

时至今日，QQ相册已经存储了超过2万亿张图片，物理存储量300PB。平均日增3亿张图片，日用户浏览数达500亿次。对比业界，可以说是当之无愧的中国第一大相册，也是世界上规模最大的图片类产品之一。

随着业务的发展，不仅用户看得到的页面样式在变，由腾讯架构平台部开发和运营的相册系统也经历了不断的优化。下面我们介绍一下QQ相册的后台架构长什么样。

如果从头搭建一个小型的相册系统，我们通常想到的架构是这样的。

索引系统存放用户的相册列表和每个相册内的图片列表。文件系统存放实际的图片文件。

实际上最早的QQ相册系统，就是直接用MySQL存储用户索引，Linux文件系统存放图片文件。这是一个最简易的系统，能够满足少量的用户和基本的功能。在面对相册用户和请求量急速增长的过程中，部门针对性地研发了底层的TFS存储系统家族KV引擎进行支撑。

索引

针对相册用户量大、读写频繁、操作数据小、需要支持平滑扩容等特点，TFS推出了基于大容量SSD的分布式K-V存储平台TSSD。通过多副本保证数据可靠性，通过自研持久化存储引擎解决随机写性能瓶颈，结合SSD与生俱来的随机读优势，使得TSSD具备出色的混合读写性能，单台峰值10万+次的读写IOPS。在支持高并发读写的同时， 独有的IO延时毛刺控制技术，使得运营中99.9%读写访问延时低于10ms。

此外，针对用户行为进行分析，发现有大量的用户操作只是拉取相册和图片列表，并没有去查看图片的详细信息。对此，我们对用户索引进行了轻重分离，将列表所需关键信息和其他详细信息分开存储，大大降低了每次操作平均读写的索引数据块大小。

压缩

QQ相册支持JPG、PNG、GIF等主流图片格式，并且在保证图片质量的前提下不断尝试和使用压缩比更高的新格式。比如已经全面支持WebP，比JPG节约存储和带宽30%。目前正在推进使用公司自研图片格式sharpP，对比WebP体积还减少15%以上。

为了应对超大并发量的压缩请求，我们搭建了几千台机器规模的压缩集群。并且这部分压缩集群大部分使用Docker技术，和现有业务机器混用，显著节约了成本。 对于时延敏感的场景，我们还推广使用了FPGA硬件压缩卡，耗时仅为CPU机器的10%。这项能力目前也通过腾讯云对外开放。

园区分布

10亿+的相册用户被逻辑上划分到不同的园区，每个园区都有一套完整的服务。每个园区可以平滑扩容，园区也可以按需增加。

就近上传

为了保证索引信息的一致性，每个用户的完整索引信息最终只会保存在某一个特定园区。用户的园区归属信息是预先划分好的。比如一个用户的索引归属信息在上海，他在深圳出差期间，如果每次上传需要访问上海的服务器，延时将很高。

为此我们后台进行了就近上传的改造，用户上传图片时，会根据地域、运营商接入最近的上传园区，并就近落地图片数据。索引归属信息则由我们的server在后台进行同步。很大程度提高了上传成功率，降低了响应时延。

异地容灾

当程序感知到某个园区发生网络故障等情况时，数据和索引可以写入备份点。多个园区之间形成了一个环状备份关系。

下载加速

在全国建立了30+个CDN加速点，就近为用户提供下载服务。还建有中国香港和美国加速点，为海外用户提供加速。

cache预推送

根据对用户行为的分析，最近上传的图片访问量往往最大。为了给用户提供更好的下载体验，在用户上传相册后，我们会预先发送指令给CDN加速点通知它们拉取图片进行缓存，当后续用户的好友进行访问时，能够快速加载，无需回源。

未来我们还会在提升服务质量和稳定性上继续努力，让网友们放心、便捷地使用QQ相册来记录生活点滴。

文章来自：腾讯架构师