采访嘉宾 | 腾讯云副总裁谢明等

图源 | 视觉中国

来源 | CSDN（ID:CSDNnews）

在腾讯内部，负责腾讯存储技术研发的部门，一直被认为是生产技术专家的“黄埔军校”。腾讯不少技术方向的负责人，最早也都出自这个团队。

这或许可以看出这只团队的底蕴——对于腾讯来说，存储是几乎所有业务开展的基础，存储技术和架构的迭代是腾讯最关注的技术方向之一。

作为海量数据的坚实承载，腾讯存储技术支撑了微信、QQ、QZone、邮件、微云、流媒体等内部业务的快速发展，同时也为快手、OPPO、小红书、海康、猎豹、58同城等几十多万个客户腾讯云上客户提供了可靠的服务，整体数据量高达EB级别。

本文中，我们将采访腾讯云存储技术相关负责人，深度揭秘腾讯云存储从零开始，到如今支撑起ZB级数据存储系统的技术演进历程，以及背后一些有趣的故事。

腾讯存储技术演进历程

腾讯存储技术的演进基本上可以分为以下阶段：

1. 海量存储(2005~2010)，支撑社交网络，构平台，撑海量

腾讯存储技术的发展，起源于2005年前后国内社交网络兴起。QQ、QZone（相册）业务的发展带来了海量的图片、文件、头像等UGC数据。为应对海量存储的挑战，腾讯云开始自研并构建了几套核心存储平台，包括TFS(通用性存储平台）,CTFS(数据频删型存储，用于短期临时存储)，TDB(基于HDD的键值对存储平台)，TSSD（基于SSD的键值对存储平台）。

这些自研平台为腾讯对象存储的发展奠定了基础。基于存储SET容量模型，腾讯云构建起标准可控的运营体系，支撑起了QQ空间、微云、QQ等产品的海量存储需求。

2. 跨地分布(2011~2013)，分拆大体量业务，搬数据，腾机房

2011~2013年，QQ相册等大体量业务的访问量、存储量迅速增长，对深圳的三通机房在机架、带宽方面产生了较大压力。为应对底层机房，带宽等方面的瓶颈，存储平台启动了相册一通点等项目，海量业务数据开始从深圳向西安、杭州、广州、上海等地分布，访问带宽同时调度到天津、南京、东莞等成本更低的一通机房。

存储平台在做数据分布搬迁的过程中，自身也在同步迭代演进。比如TFS从3份存储演进为同时支持1/2/3份数据的多副本存储；CTFS从2份存储演进为同时支持2/3份数据存储。TSSD平台也从仅支持单机独享的Uin-Value定制存储演进为支持多租户的通用Key-Value存储。

3. 冷存储（2014~2015)，分离冷数据，降份数，省成本

腾讯相册、微云、邮件等业务在业务发展中，逐步积累起来较多的UGC历史数据，这些历史数据访问量低、存储量大，对业务的运营成本构成了较大的压力。为了应对冷数据存储的成本挑战，2015年前后，腾讯基于纠删码研发了BTFS平台(Backup-TFS)。对业务进行了数据分层，增量数据访问量大，用TFS存储3份；历史冷数据从TFS平台剥离出来，从3副本存储转向1.33副本的纠删存储，降低了存储成本。这个阶段中，腾讯优化BTFS，使得部分低访问量业务的增量数据也可以直接存储进来。

4. 云存储磨合期(2016~2017)，重构系统，兼容接口

在磨合期，腾讯云基于已有的存储访问接口和平台架构对外提供服务。经过一段时间的运营，腾讯云发现外部第三方业务在体验、可用性、成本等诸多运营方面有极高的要求。为支撑云的需求场景，腾讯云对存储的接入层和索引层架构进行重构，架构扁平，模块精简，同时开始舍弃私有接口，转为兼容AWS S3接口与功能。重构后存储架构支撑了腾讯云COS近几年的发展。（注：对象存储COS，CloudObjectStorage，是由腾讯云推出的安全稳定、便捷易用、低成本的海量云端存储服务。）

5. 多云时代（2018~)，对标行业，比成本，拼质量

伴随公有云的逐步普及，用户存储的数据成几何倍数增长，硬件发展日新月异，公有云提供商间的竞争日趋激烈。2017年，腾讯云的数据量突破一个EB，成为腾讯存储历史上的一个标志性节点。

AWS S3的存储访问接口已成为公有云上对象存储事实上的行业标准，存储成本、运营质量成为客户上云选择产品提供方的主要考量。

在这一阶段，腾讯重新审视了机房，机型等方面的技术演进趋势，重构了公有云对象存储引擎（详解见下文）。新架构采用大容量高密度存储机型，针对存储SET导致的闲置资源分散和隔离等多个主要矛盾，进行了全面应对和优化。

先从整体上对腾讯云存储有了一个大致了解后，我们再从各阶段一些重要节点事件，来了解腾讯云存储技术演变背后的逻辑，供业内参考。

七八个人搞了TFS

2005年，QQ空间发布，大量存储需求爆发。

腾讯云副总裁 、云架构平台部总经理谢明，以及腾讯云架构平台部系统研发中心总监郭振宇，都是腾讯云在2005-2006年开始做统一存储架构时期的重要亲历者。

2003-2004年，谷歌发表了俗称“三大件”的论文，即BigTable、GFS和MapReduce，这是从原先的企业级存储向互联网时代大规模使用廉价的分布式存储的一个较早期的实践。

受此启发，谢明、郭振宇与团队中七八个人开始做通用性存储平台TFS，把RPC框架和通信协议、存储相关的数据迁移、巡检系统等逐步做起来，第二年初就将这套存储系统用到了 QQ 相册。

用上TFS后，QQ相册解除了每天800万张图片的上传限制，结束了那段只有QQ黄钻用户才能无限上传图片的历史，普通用户再也无需凌晨24点守在电脑前抢着上传图片。

但与谷歌 GFS 主要面对搜索场景，因此主要解决的问题是大文件存储不同，腾讯的业务里图片较多，小文件才是要解决的主要问题，但是TFS并不适合做小文件存储，因此又创建了KV存储平台——TDB。

再往后，腾讯云的业务中又出现了一些需要频繁删除的场景，CTFS应运而生，用于短期的临时存储。这套系统在频删型的场景，如文件中转站中非常实用。积累了一定口碑后，其他业务也逐渐迁移到CTFS。

除了这些，团队还针对业务场景进行用户体验优化，例如优化了索引。原先的文件系统索引有很多层，拓展性强，但是每次硬盘要进行多次访问。当文件较大，硬盘多次访问会造成延时。为此，TFS设计之初就力争硬盘只访问一次，把chunkID（段表示）和FID索引放在一起，用户读取索引时就能知道图片在哪块盘上，只要访问一次硬盘就能读取图片，减少磁盘IO次数提升了用户体验。

之后，TFS又陆续被用于网络硬盘、QQ邮箱等产品中。

腾讯史上最大数据搬迁

时间到了2009年，腾讯日益扩张的业务与激增的数据量使得存储的访问带宽问题暴露出来。

2009年腾讯存储团队合影

那时，腾讯几乎所有的数据都在深圳，但当时国内的骨干网宽带与现在不可同日而语。QQ相册高峰时占用40-50G，而1G的流量对公司的网络就已经是很大的负担了。因此，在控制带宽高峰的驱动下，腾讯开始考虑把存储向西安搬迁。

谢明回忆，当时搬迁的第一个设备的数据量是100T。现在看来，这个数字也许并不大，但当时却是腾讯历史上最大的一次数据搬迁，因为那时候基本上没有专线可用，数据搬迁都是趁着半夜公网空闲搬迁过去的！

微信红包爆发带来存储压力

2014-2015 年，移动互联网崛起。

在这期间，腾讯也有两件大事发生。一是微信开始流行，2014年除夕的微信红包，连带着朋友圈的图片分享让微信火爆起来。原来在 PC 时代春节期间不怎么值班的腾讯工程师们发现，春节期间不得不安排更多人值班了，以应对除夕和元旦凌晨12点到12点10分这十分钟内，抢红包和图片发布剧增的数据。腾讯的存储系统面临着史无前例的压力。

2016年腾讯存储团队春节值班零点后留影

为此，谢明团队与微信团队沟通，对大型缓存系统、延时通知等技术进行改进。水来土掩，兵来将挡，到2015年腾讯存储已经可以应对除夕夜突发性问题。

第二件大事是网络硬盘的发展给存储带来很大的成本压力。作为一项免费服务，如何控制成本成了谢明团队的又一个巨大的挑战。为此，团队于2014年完成并上线了基于纠删码的BTFS平台。

业务也是技术发展的助推器

腾讯云存储技术能力的不断完善，也离不开业务不断提出的挑战。

郭振宇举了两个例子来说明当时团队面临的挑战，一个是微信与海外同类产品，如在东南亚人气很高的Line和WhatsApp。为了在竞争中获得优势，微信做了很多事情，比如东南亚用户与国内进行数据沟通时链路很长，团队就基于存储做了加速通道，从而加速了国内外数据传输，速度超过Line和WhatsApp。

另一个例子是游戏，QQ农场相信对于每个90后都不陌生，但不一定有人了解，全民偷菜的热情曾让腾讯的服务器数度崩溃。当时，农场访问量巨大，但腾讯还没有全存储系统，TDB是基于SAS盘存储的，在每秒数万的并发访问下，底层存储系统的延时和请求吞吐挑战非常大。

腾讯基本上把公司所有闲置服务器都用在QQ农场，但仍远远不够，需要大量采购服务器。团队一方面通过疯狂的机器扩容，另一方面基于数据规模不太大但是访问量极高的业务特点，快速研发了全内存的分布式存储系统，在保障数据安全可靠的前提下，并发访问的性能得到极大提升。快速上线、快速验证，完全自研，团队再次闯关成功，“修为”再上一层楼。

从开放平台到服务B端，很多事情变了

面向B端客户提供服务，是腾讯云存储技术的另一个关键节点。

从2010年起，腾讯就开始做开放平台云。2013年，腾讯云正式面向B端用户全面开放。

在计算云迅猛发展的大背景下，行业竞争日益激烈，客户可选择面较大，对功能、性能、质量、价格等方面的需求不断增强。

此外，从腾讯云自身现状来说，数据量的不断增大，随之带来软硬件成本、运维成本优化的收益日趋增大。

同时，行业下游的基础设施，如大型数据中心、新机型、新硬件、各种存储介质、网络环境的不断发展演进。相比十几年前，单个IDC机房从数千台，到腾讯目前超百万装机量超大规模机房；网络从千M网卡，发展到百G网卡，整个基础设施发生了天翻地覆的变化。

这些变化，都在呼唤腾讯云在存储系统架构上做出改变。

YottaStore，打破传统IT存储系统架构

腾讯云从2017年开始构思，并于2018年正式启动了下一代云原生对象存储系统设计——YottaStore。

名字由来

YottaStore这个名字实际上取得很有深意，腾讯云架构平台部存储研发中心总监杨奋强介绍了Yotta这个词背后的含义。

对于做存储的同学来说，经常会跟GB、TB、PB、EB这些概念打交道。现在全球互联网非常大的巨头公司的数据量基本都是在EB这个量级。EB上面是ZB，全球互联网巨头数据起来也就几个ZB；ZB上面是YB，也就是YottaByte，目前全世界所有的数据加起来也不会超过一个Yotta。另外这个单词中文译名“有他”，给人安全可靠放心的感觉，系统的Slogan就是“存储有他，能力无限”。

所以，Yotta——有他既是腾讯存储同学们对这个系统海量数据存储能力的深厚期望，也是对服务质量和可靠性的巨大承诺。为了实现上述期望和承诺，YottaStore实现了众多业界独一无二的技术突破。

技术突破

集群规模：YottaStore是一个云原生的数据存储系统，这个系统的理论极限是一个集群可以管理超上千万台服务器。而要管理这上千万台的机器，元数据管理只需要用600G左右的空间，用一台机器就能存下索引结构，这在业界是绝无仅有的。

资源利用率：当集群规模非常大的时候，其实1%的剩余空间量都是非常非常大的，所以YottaStore的硬盘利用率非常高，加上实时回收机制，有效数据占比达90%以上，这在业界非常少见。

另外，由于大集群的全集群均衡能力，服务器资源使用均衡，所以资源使用率也可以做得很高，这样服务器硬件可以最低位配置，所有尖峰流量在这个异常大的池子里，波澜不惊。所以无论是成本、还是服务能力，都很大程度受益于超大规模集群带来的红利。

灵活性：YottaStore单集群可以零研发成本同时支持各种不同的冗余模式，像两副本、三副本、四副本、五副本，任意的EC编码，任意的M、加任意的N、任意的算法；单AZ、双AZ、多AZ也都可以灵活支持；另外，整个集群可以自适应各种各样不同的机型，包括JBOD；各种硬盘介质，如磁带、HDD、SSD等，存储的拓扑结构、混合部署也都可以任意指定。这样的灵活性在业界首屈一指。

运营能力：以存储节点迭代升级为例，十万百万规模的一个集群，上线升级速度都是一样的，如果是同构的数据格式，分钟级就可以完成整个升级过程；而如果是异构的数据格式，集群可以在短时间内自动将数据格式透明收敛到最新版。

可用性：YottaStore开始上线大规模支撑业务的前三个月一直维持百分之百的可用性，到现在一年半了，系统一直单人值周零故障运行，在业界是极少见的。可用性数个9很容易，但是可用性100%非常难。例如机房网络抖动，如果容错做的不够好，就很容易就会出现失败。但是YottaStore在初期上线的很长一段时间都是百分之百的可用性。

业务支撑

YottaStore是腾讯云对象存储服务COS的数据存储引擎，支撑起整个腾讯云海量数据的存储。COS的标准存储、低频存储、归档存储、多AZ存储等产品形态都是基于YottaStore推出。

得益于YottaStore在集群规模、资源利用率、灵活性等方面的技术突破，近期COS重磅推出的深度归档产品刷新了业界存储的最低价：1分钱/GB/月。

激烈竞争环境下，成本是存储业务胜出的关键因素之一。YottaStore是如何优化成本的呢？

资源利用率提高：基于前文所述的在超大规模集群和超高资源利用率上的技术突破，随着资源利用率的增高，单位存储的成本随之降低。

高密硬件适配：随着磁盘容量扩大，单机磁盘数变多密度增高，成本也随之降低；此外，CPU、网卡等新硬件的变化都会导致成本降低。

场景优化：针对海量小文件的用户场景，YottaStore采用多种冗余和数据组织策略持续优化成本。

此外，对于一套承载着用户业务数据的存储系统来说，数据一个都不能丢、安全可靠是最重要的承诺。在数据可靠性方面，YottaStore在数据冗余、数据巡检、数据修复、数据校验等方面做了很多工作，保障了数据的可靠性。

到这里，我们回顾了腾讯云存储技术发展的全部历程，也得以从中一窥互联网大厂在底层存储技术与业务发展紧密结合，“配合作战”成功的秘诀，希望对业内有一定的启发。云时代下，腾讯云存储还将有哪些创新，我们拭目以待。

更多阅读推荐

• 荷兰政府用大数据预测天气预防自然灾害，他们是怎么做的？
  阿里云资深技术专家易立：我对云原生软件架构的观察与思考

• SQL分页查询方案的性能对比

• 蚂蚁集团两地上市暂缓，阿里巴巴股价大跌，员工快到手的大 House 飞了！

• 离职后竟半夜偷溜回办公室写代码？一个为自由软件而战斗的程序员