架构解密：QQ空间相册的后台长什么样？

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

时至今日，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相册来记录生活点滴。
 

来源：腾讯架构师