伸手党福利 - 直击TFS技术内幕

作者介绍:傅飞玲, 2011年毕业进入腾讯公司,在TEG-架构平台部从事分布式存储领域相关研发工作,在海量分布式存储、高性能服务、存储运营系统的建设以及运营故障的诊断积累了一定经验。致力于建设公司级存储平台,携手业务为用户提供安全、可靠、高效的数据存储服务。

TFS(Tencent File System)是腾讯架构平台部自研海量文件系统,自2006年平台上线,经过多年不断技术演进,目前TFS承载了包括QZone相册、微信朋友圈图片、QQ邮件、微云、腾讯云COS等公司重要产品的数据存储,截止到2017年年初,TFS承载的数据突破1EB。

一、TFS平台概述

TFS平台提供以文件为粒度的上传,下载,删除等数据访问服务,系统分为接入,文件索引,索引存储,数据存储四个部分。接入层串联文件上传、下载、删除、查询索引等关键流程,提供简单的事务机制;文件索引层管理文件的元数据;索引存储提供key-value接口的分布式存储和访问(TSSD),用于存储文件的元数据;数据存储提供基于机械磁盘的数据存储和访问,用于存储文件内容。以QZone相册为例,索引存储中保存着相册列表、图片排重索引以及图片数据的原信息,而文件索引层则负责上面三种索引的逻辑组织,图片数据存储在数据存储层中。

二、文件索引 -- 3D Indexing技术

3D Indexing技术作为TFS文件存储中索引设计的桥梁,连接了索引存储和数据存储。它包括文件索引、用户目录、排重索引,不仅满足基本的文件存储需求,还支持了同一目录下千万级文件个数的用户目录,以及追求最优成本的排重索引。

文件索引

面对丰富业务场景,TFS上的文件长度从几KB到几十GB都有,大文件对文件的上传、下载、存储都带来很大的挑战。TFS文件索引支持大小灵活伸缩,文件最大可达1TB,同时带来文件并发上传、下载提升用户体验的好处。

TFS将文件切分成多个数据分块存储在数据存储集群中,文件索引维护文件中所有分块在数据存储的位置等元数据,将元数据存储在索引存储TSSD中。通过文件索引可以到元数据中指向的数据存储集群中获取到文件数据分块,串联起索引存储和数据存储,支持文件存储。

目录索引

文件存储中,常见目录类应用场景如QZone相册、微云网盘,每个用户的所有文件、图片都使用目录功能来管理。TFS早期将同一目录下的文件、目录索引打包存储到一条Key-Value中来提供通用的用户目录索引的解决方案。随着业务发展目录下文件数越来越多,部分用户需要超过十万的超大目录景,这些大目录的查找效率、流量都成为瓶颈。

TFS采用分拆目录索引的方式,将目录下超长列表按字典顺序分段存储在多个扩展记录中,在主目录索引下记录所有扩展记录key以及列表范围。分而治之的思路不仅加速大目录下增删改查的性能、降低了延时,也提供了同一目录下千万级文件个数的用户目录功能。

排重索引

TFS平台针对用户数据在云端多份存储常见的场景,特别是热点视频、图片、安装包等,对文件和数据分块都支持了排重,以QZone相册为例,排重率大于36%,而微云则超过了55%,排重效果可观。数据排重为用户提供了图片、文件秒传,既优化大文件上传的用户体验,也降低存储成本。

三、TFS索引存储 -- 高性能Key-Value存储TSSD

TFS的索引数据落在基于SSD盘的高性能分布式Key-Value存储系统TSSD中,采用MHT数据分布技术,以及基于混合索引的存储引擎,具有高性能、低成本、低延时、运营可控的特点。

TSSD整体架构见下图,其中Access为接入服务器,负责前端业务的接入;Master为元数据服务器,负责资源和路由的管理;Cell为存储服务器,负责数据的磁盘存储。

3.1 MHT数据分布技术

对于分布式KEY-VALUE存储来说,首先要解决如根据Key快速定位数据所在位置(存储节点,磁盘,盘内偏移)。业界常用分布式哈希(DHT)或者中心化路由等技术来解决数据分布化的问题,典型代表有Google的BigTable、HDFS等, 但这些方案存在伸缩性不足,运营可控性差的缺点。

TSSD的MHT(Managed Hash Table)的数据分布技术,拥有DHT的分布式无中心节点的路由访问容错性的同时兼顾了中心化集中式的路由的可控性。MHT技术中,路由表基于100万的一致性哈希虚拟节点,大小可控有利于路由同步、缓存;Master作为中心节点负责路由管理,提供日常运营副本状态、节点更替等路由变化功能;在可平行扩展的access中缓存路由、增量同步,解决中心节点单点瓶颈问题;存储节点上实现路由访问校验,为数据安全加一层保障。

基于MHT技术,我们在运营中还实现了双读去毛刺和平滑扩容

双读去毛刺。线上运营中,经常遇到磁盘毛刺严重、网络抖动等影响业务质量的问题,TSSD通过双读策略解决访问毛刺问题,在SSD磁盘高负载毛刺率(>100ms)较高1%的情况下,TSSD做到了99.99%的请求都低于100ms。在接入层实现双读访问控制:遇到读取副本超时未响应时从其他副本读取数据,发挥多副本的优势。

平滑扩容。节点故障离线、增加节点带来数据腾挪均衡是常态,而数据腾挪是一个离线的过程,如何保证在线访问新写数据不丢呢?TSSD在接入层加入数据搬迁中的源和目标存储单元串联双写的访问控制,实现平滑扩容,扩容过程可进可退。

3.2 混合索引存储引擎

TSSD存储支持了记录大小从几十字节到几百KB业务场,业务特性为读多写少场景,所以需要一个记录大小灵活且读性能高的存储引擎。目前业界常用的存储引擎有B+树(MySQL), LevelDB/RocksDB等,这些存储引擎存在读性能差,SSD写放大导致固态盘使用寿命短等问题。

混合索引技术。我们在运营中针对SSD固态硬盘自研了基于混合索引的存储引擎,该引擎具有读效率高,读写IO延时波动小,无SSD写放大等优点。在有限的内存基础上实现记录全索引,读请求都是一次磁盘访问,保证可控的读效率。记录较小场景下,内存索引先被耗尽导致磁盘利用率低、空间浪费的问题,通过混合索引技术得到很好的解决。

TSSD以小于4KB的记录为小记录,将小记录哈希到桶索引、大记录独立索引混合放在内存中。读访问时,通过索引查询判断是大记录、桶记录,通过相应索引从磁盘读取数据,大记录直接返回,桶记录则需要遍历查询获得对应小记录、或确认遍历不到的空记录。通过合并写,块回收的方式减少对磁盘IO的随机写入,去除对SSD盘的写放大。

主机FTL技术。业界基于SSD的存储系统设计中,都实现了垃圾回收、地址映射、IO调度的功能,与通用SSD-FTL的功能重叠,在性能、寿命上存在浪费。基于主机FTL技术,极大的精简了SSD内部设计;其中基于优先级和最差延时保证的IO读写调度算法,超过100msIO延时比例为0%;应用感知的回收算法,使得SSD随机写寿命提升6倍。

四、TFS数据存储

在丰富的业务场景驱动下,TFS的数据存储也发展出来不同的差异。根据业务的场景、数据冷热层度,提供高性能数据存储—基于存储单元结对的Append-Only存储引擎、更低成本的数据存储—一体化的纠删码存储引擎。

在TFS数据存储系统中,将文件切分的分块数据block存储在存储节点chxd;存储节点上以2GB的空间聚集多个分块数据、把2GB空间称为chunk;将分布在不同存储节点上的一个或者多个chunk组合成数据的多副本或者纠删码条带,称为chunks。通过元数据管理节点chxmaster管理chunks,并负责数据分块block空间分配、下载定位。

4.1 基于存储单元结对的Append-Only存储引擎

在众多同构存储节点,不同副本分布设计和存储引擎将是直接影响数据存储系统的性能。常见的有基于主机、磁盘结对的副本分布方式,实现设备、硬件的故障隔离,但是故障后性能与可靠性都有缺点。

TFS数据存储提供了基于存储单元chunk结对Append-Only存储引擎,具有极致的系统性能和超高数据可靠性。

副本均匀分布在集群各个故障容灾节点中,故障隔离包括磁盘、设备、基架、交换机等。在常见的磁盘、设备故障下,系统保持近乎峰值性能;且硬件故障、数据恢复上面,其他节点都参与数据快速重建,瓶颈不再集中在单节点上,数据安全性更有保证。

TFS的存储引擎跳过文件系统直接运行在“裸盘”上,优化了IO路径。每个chunk设计独立的元数据inode区和数据区,inode全内存缓存、IO对齐,数据区Append-Only追加写,实现IO极致性能以及运营可控:业务读数据时,只需访问一次数据,业务写只有一次inode、一次数据共两次写。

4.2 一体化的纠删码存储引擎

TFS文件存储主要存储的是UGC类的用户数据,访问频率随着时间推移越来越低,数据在慢慢变“冷”,需要低成本的数据存储方案。业界常见降成本的方式为对数据进行编码,在保证数据可靠性的提供,降低存储份数到1.X份,一般的有基于多副本写cache层,以及的纠删码存储层双系统架构,这种架构存在运营复杂、业务数据落地路径长的问题。

TFS一体化的纠删码存储引擎具有1.33份的低成本、高可用和数据可靠性的优点。系统使用RS纠删码9+3副本模式,将存储成本缩减到1.3份;利用指令集加速、实现高效纠删编码;简单的元数据-存储节点架构,上传写到提供写服务的chunks内并拷贝多份数据到其他故障容灾的设备上,支持服务高可用;新上传的数据通过增量编码的方式快速进行纠删编码落地,提高数据高可靠性。

五、总结

TFS存储系统通过3D Indexing索引技术,为用户提供丰富的索引功能。基于主机FTL和混合索引的大规模SSD存储和处理技术,提供高性能、低成本、运营可控的索引存储。基于存储单元结对的Append-Only存储引擎、一体化的纠删码存储引擎,助力TFS提供高性能、低成本等多种场景的数据存储。

十一年的数据极速增长,TFS从无到有、架构不断演进,后续也将持续通过数据异地分布、硬件定制等技术,继续在数据高可靠、高性能、更低成本上助力业务更好发展。

文章来源公众号:腾讯架构师(TencentArchitecture)

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

从零构建OpenStack(1) 云计算相关概念及OpenStack介绍

什么是云计算? 什么是云 相信很多人对”云”这个词云里雾里,这也恰好符合它的特性,曾经的云一般表示网络(WAN),我们经常在很多网络拓扑图中看见它的身影,如今云...

2678
来自专栏上线了的专栏

Strikingly 团队2017技术展望

为了应对多客户端(Web, iOS, Android)的挑战,2016 年我们在团队层面和技术栈上做了很大胆的尝试:我们把前端团队和移动端合并了,组成了客户端团...

3060
来自专栏CSDN技术头条

荔枝FM架构师刘耀华:异地多活IDC机房架构

声明:本文首发于CSDN,禁止未经许可的任何形式转载,可咨询文末的责编。 多机房架构存在的原因 ? 单机房一旦死机,断电、维护根本无法挽回整个数据,想离线读取等...

2496
来自专栏携程技术中心

干货 | 携程第四代架构探秘之运维基础架构升级(下)

作者简介 本文由携程技术中心框架研发部吴其敏、王兴朝,技术保障中心高峻、王潇俊、陈劼联合撰写。 作为国内最大的OTA公司,携程为数以亿计的海内外用户提供优质的旅...

3739
来自专栏互联网研发闲思录

手机QQ公众号亿级消息实时群发架构

编者按:高可用架构分享及传播在架构领域具有典型意义的文章,本文由孙子荀分享。转载请注明来自高可用架构公众号 ArchNotes。

684
来自专栏Grace development

浅谈架构是为了什么 (下)

从现在开始,假设我们自己是一个创业的小团队。没资金没人脉,靠技术打天下。现在要开发一套电商系统。开始自己的表演。

442
来自专栏SDNLAB

SDN实战团分享(三十二):ZStack架构及其网络功能简介

先说些题外话 SDN 群里大牛很多,从平时讨论中学习到不少,我的背景相对更偏云计算一些,我对 SDN 的角度可能也与大家有一些不同。 举例来说,前段时间发生了...

4105
来自专栏不止思考

如何应对线上故障

线上故障是我们技术同学经常遇到,也是技术成长中经常要经历的事。从故障中我们可以吸取到很多教训,变得越来越有经验。

1102
来自专栏大数据文摘

大型网站系统架构演化之路

1775
来自专栏斑斓

系统架构 | 基于微服务架构,改造企业核心系统之实践

背景与挑战 随着公司国际化战略的推行以及本土业务的高速发展,后台支撑系统已经不堪重负。 在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万...

2995

扫码关注云+社区