快手春节红包背后，高并发存储架构设计

2020年春节，腾讯云文件存储（CFS）在通过了预演层层压测的选拔后成为快手广告推荐业务的护旗手，以100%的可用性护航了快手春节红包活动。本文是腾讯云高级工程师陈宏亮在「腾讯云开发者社区沙龙online」的分享整理，为大家带来应对单文件大吞吐高并发的存储架构设计方案！

一、快手红包案例背景

2020年的春节，想必大家都印象深刻，除了新冠肺炎疫情，就是春晚各大APP的红包大战，让不少用户“薅”到了羊毛。

大年三十看春晚，多年来已成为中国人的过年传统之一。春晚是覆盖全国各线城市和广大乡村的超过10亿观众的超级流量入口，可以迅速帮助互联网巨头们实现下沉、导流和拉新。

事实上，红包早已不是单纯的红包，已经成为超级流量入口和新的强大增长引擎。在“红包”发放和领取的背后，包括大数据、云计算、支付结算等一系列的变革。

过去五年来，央视春晚的舞台一直都是BAT的天下。但今年快手在竞标过程中PK掉了阿里、拼多多和字节跳动后，成功竞标成为央视春晚独家合作伙伴。而其他公司虽然没有竞标到春晚的独家合作，但是在2020年春节那个疯狂的除夕夜，他们依然投入了巨资，加入了春节红包这场混战。

一场围绕着春节、民俗和亲情的全民红包大战已经成为各互联网巨头每年农历年底最重磅的营销活动。

而最终的战果，根据快手官方披露的 “春节 10 亿现金红包” 活动成果数据显示：春晚期间，快手红包互动总量高达 639 亿次，创春晚史上最大的视频点赞纪录；红包站外分享次数达到创纪录的 5.9 亿次。快手春晚直播间累计观看人次 7.8 亿，最高同时在线人数 2524 万。而在整个春节假期，快手平均日活跃用户规模上涨 40%！

面对如此惊人的使用数据及业务增量，在快手背后默默提供支持的腾讯云很能感同身受其背后的付出，而在这其中，腾讯云文件存储 CFS 在通过了层层压测的选拔后成为快手广告推荐业务的护旗手。

快手作为泛互联网行业的头部客户，春节期间快手联合央视春晚推出“上快手，分6亿现金”春节红包活动、业务量肯定会有大规模激增；春节业务期间，CFS 文件存储主要与TKE容器节点搭配，在客户关键的应用 -- 广告推荐业务上为其提供专项保障。

二、快手业务场景需求分析以及面对的挑战

1. 快手业务场景分析

广告推荐，顾名思义就是用户在使用应用期间会看到的各种引诱你“买买买”的小弹窗、小视频、banner等。互联网的精准营销会根据用户信息、使用行为，结合提前训练好的推荐模型来为该用户精准推送最适合的广告，从而提高金主爸爸们营销资金利用率。

CFS 参与的快手应用广告推荐的具体业务流程主要分为如下三步：

第一步，模型文件发布。

广告模型训练过程在客户数据中心完成，训练完成后将模型文件发布到腾讯云。

第二步，业务应用获取模型。

春节期间，快手在腾讯云上使用了 3 个 TKE 容器集群共计 4000+ Node、Pod 数量超过 8000 个，以分摊业务压力。这些 Pod 要将所需的几十 GB 不等的一组模型文件全部加载后（该组合总共若干组），应用才能启动。

第三步，广告推荐。

系统使用模型文件结合用户数据，实时为用户定制广告推送。

2. 快手广告业务架构图

使用场景：在业务启动时，应用程序需要读取广告推荐模型文件；在运行过程中，系统根据用户使用数据进行广告推荐。

客户IDC计算节点挂载CFS，拷贝本地推理模型数据到CFS中，再通过腾讯云TKE业务集群，挂载NFS客户端来从CFS中来读取客户训练集群生成的推理模型数据。

在业务启动的时候，应用程序需要去读取广告推荐模型的文件。在运行的过程中，系统会根据用户的使用数据来进行广告推荐。

通过对业务流程的摸底，我们大致了解了这部分业务的存储背景，数据流程以及业务规模，但是我们的产品能否解决客户的问题，还需要更进一步的深入了解。

3. 快手业务需求分析

通常对于存储产品选型来说，关键性衡量指标包括业务性能需求、容量需求以及具体 IO 模型。腾讯云在经过反复与快手运维同学沟通、结合测试数据分析，得出该场景内的存储需求如下：

（1）详细需求

• 吞吐需求：5 GB/s（40Gbps）
• 单文件大小：KB 到 十几 GB
• 并发客户端：最大 8 K个 Pod
• 元数据ls操作：偶尔
• 计算节点信息: TKE Node 配置为 84C 320G, 单 Node 生产 2 个或 4 个 Pod

（2）场景特点

• 数据以读为主：客户从 IDC 拷贝到 CFS 上的文件不会修改，只有很小的概率会删除/新增；
• 大文件为主：且用户一组文件以一个十几GB的大文件为主、外加少量MB及KB级的小文件；

快手的业务场景，它有两个非常明显的特点，这两个特点为我们后续对架构进行优化，满足快速的需求提供了基础。第一就是数据主要是以读为主，客户从IDC拷贝到CFS上的文件，基本上是不会修改的，至多有很小的概率可能会删除或者新增。

另外一个特点就是存储以大文件为主，用户的一组文件主要是以十几G级别的大文件为主，可能还会有少量的MB或者KB级的小文件，但是基本上可以忽略不计。

（3）案例难点

当然，从单文件系统的指标数据上来看，CFS 应付这些场面是绰绰有余。但是在实际使用中，不同的数据 IO 模型对存储的具体要求就可能存在巨大差别。而 CFS 此次遇到的主要有两个难点，第一是单文件大吞吐、第二是数千并发连接。

对于单文件大吞吐：最极端情况下会有 2000 个 Pod 同时读一个文件，每个 Pod 上业务的启动都依赖于整组文件完全读取，需求总吞吐能达到 5GB/s（由于当前架构限制，CFS 还未支持文件分片存储，因此单文件吞吐受到限制）；

对于数千并发连接：客户云上业务总共 4000+ Node,  最多 8000 个Pod会随机分布在各 Node 上。

三、NFS协议介绍

1. NFS概述

NFS（Network File System，网络文件系统）是一种基于网络的文件系统， 是文件系统之上的一个网络抽象，来允许远程客户端以与本地文件系统类似的方式，来通过网络进行访问。

它可以将远端服务器文件系统的目录挂载到本地文件系统的目录上，允许用户或者应用程序像访问本地文件系统的目录结构一样，访问远端服务器文件系统的目录结构，而无需理会远端服务器文件系统和本地文件系统的具体类型，非常方便地实现了目录和文件在不同机器上进行共享。

虽然 NFS 不是第一个此类系统，但它无疑是最成功一个，它已经发展并演变成 UNIX® 系统中最强大最广泛使用的网络文件系统。

2. NFS历史

NFS 的第一个版本是 SUN Microsystems 在 20 世纪 80 年代开发出来的，至今为止，NFS 经历了 NFS，NFSv2，NFSv3 和 NFSv4 共四个版本。现在，NFS 最新的版本是 4.1，也被称为 pNFS（parallel NFS，并行网络文件系统）。

在 20 世纪 80 年代，它首先作为实验文件系统，由 Sun Microsystems 在内部完成开发。NFS 协议已归档为 Request for Comments（RFC）标准，并演化为大家熟知的 NFSv2。

当协议标准演化到NFSv3时，其在 RFC 1813 中有定义。这一新的协议比以前的版本具有更好的可扩展性，支持更大的文件（超过 2GB），异步写入，以及支持将 TCP 作为传输协议，这些为文件系统在更广泛的网络中使用铺平了道路。

在 2000 年，RFC 3010（后面由 RFC 3530 进行了修订）定义了NFSv4，相比于之前的版本，它具有较高的安全性，并且带有状态协议（NFS 之前的版本都是无状态的）。后续，NFS 发展到了版本 4.1（由 RFC 5661 定义），它增加了对跨越分布式服务器的并行访问的支持（称为 pNFS extension）。

NFS 已经历了几乎 30 年的发展，作为一个非常稳定的（及可移植的）网络文件系统，它的可扩展以及高性能都达到了企业级的质量。由于网络速度的增加和延迟的降低，NFS 一直是通过网络提供文件系统服务最具有吸引力的选择。

3. NFS实现原理

那么，NFS究竟是如何做到像访问本地文件一样通过网络访问远端的文件的？

首先回答最常见的问题，什么是文件系统？文件系统是对一个存储设备上的数据和元数据进行组织的机制。Linux 文件系统体系结构是一个对复杂系统进行抽象化的有趣例子。通过使用一组通用的 API 函数，Linux 可以在许多种存储设备上支持许多种文件系统。

例如，read 函数调用可以从指定的文件描述符读取一定数量的字节。read 函数不了解文件系统的类型，比如 ext3 或 NFS。它也不了解文件系统所在的存储媒体，比如Serial-Attached SCSI（SAS）磁盘或 Serial Advanced Technology Attachment（SATA）磁盘。但是，当通过调用 read 函数读取一个文件时，数据会正常返回。

用户空间包含一些应用程序（例如，文件系统的使用者）和 GNU C 库（glibc），它们为文件系统调用（打开、读取、写和关闭）提供用户接口。系统调用接口的作用就像是交换器，它将系统调用从用户空间发送到内核空间中的适当端点。

虚拟文件系统VFS 是底层文件系统的主要接口。这个组件导出一组接口，然后将它们抽象到各个文件系统，各个文件系统的行为可能差异很大。有两个针对文件系统对象的缓存（inode 和 dentry）。它们缓存最近使用过的文件系统对象。

每个文件系统实现（比如 ext4、NFS 等等）导出一组通用接口，供 VFS 使用。缓冲区缓存会缓存文件系统和相关块设备之间的请求。例如，对底层设备驱动程序的读写请求会通过缓冲区缓存来传递。这就允许在其中缓存请求，减少访问物理设备的次数，加快访问速度。

用户或者应用程序通过统一的系统调用接口对文件系统进行操作，然后系统调用进入虚拟文件系统层，虚拟文件系统根据文件系统类型，调用特定文件系统的操作函数。对用户和应用程序来说，由于接口完全相同，因此用户感觉不到差异，应用程序也可以无缝地移植到 NFS 文件系统上。

Linux 通过一组对象对文件系统进行操作，这组对象是 superblock（超级块对象），inode（索引节点对象），dentry（目录项对象）和 file（文件对象）。

所有文件系统都支持这些对象，正是因为它们，VFS 层可以对 NFS 和其它文件系统一视同仁，只管调用这些对象的数据和函数指针，把具体的文件系统数据布局和操作都留给特定的文件系统来完成。

4. NFS堆栈

在 Linux® 中，虚拟文件系统（VFS）提供在一个主机上支持多个并发文件系统的方法。VFS 一旦发现了为 NFS 指定的请求，VFS 会将其传递给内核中的 NFS 实例。NFS 解释 I/O 请求并将其翻译为 NFS 操作（OPEN、ACCESS、CREATE、READ、CLOSE、REMOVE 等等）。

这些操作，归档在特定 NFS RFC 中，指定了 NFS 协议中的行为。一旦从 I/O 请求中选择了具体操作，它会在远程程序调用（RPC）层中执行。

正如其名称所暗示的，RPC 提供了在系统间执行程序调用的方法。它将封装 NFS 请求，并伴有参数，然后将它们发送到合适的远程对等级，然后管理并追踪响应，提供给合适的请求者。

进一步来说，RPC 包括重要的互操作层，称为外部数据表示（XDR），它确保当涉及到数据类型时，所有 NFS 参与者使用相同的数据表示。当服务端处理请求时，数据类型表示可能不同于客户端的数据类型。XDR 负责将类型转换为公共表示（XDR），便于所有架构能够与共享文件系统互操作。

一旦 XDR 将数据转换为公共表示，请求就通过网络传输给服务端。早期 NFS 采用 Universal Datagram Protocol（UDP），但是，今天 TCP 因为其优越的可靠性而更加通用。

在服务器端，NFS 以相似的风格运行。当请求到达网络协议栈，通过 RPC/XDR（将数据类型转换为服务器架构类型）然后到达 NFS 服务器。NFS 服务器负责处理请求。请求向上提交给 NFS 守护进程，它为请求标示出目标文件系统树，并且 VFS 再次用于在本地存储中获取文件系统。

整个流如下图所示，注意：服务器中的本地文件系统是典型的 Linux 文件系统（比如 ext4fs）。因此，NFS 不是传统意义上的文件系统，而是访问远程文件系统的协议。

四、CFS简介

1. 文件存储概述

文件存储（Cloud File Storage，CFS）提供了可扩展的共享文件存储服务，可与腾讯云的 CVM 、容器、批量计算等服务搭配使用。

CFS 提供了标准的 NFS 及 CIFS/SMB 文件系统访问协议，为多个 CVM 实例或其他计算服务提供共享的数据源，支持弹性容量和性能的扩展，现有应用无需修改即可挂载使用，是一种高可用、高可靠的分布式文件系统，适合于大数据分析、媒体处理和内容管理等场景。

文件存储接入简单，您无需调节自身业务结构，或者是进行复杂的配置。只需三步即可完成文件系统的接入和使用：创建文件系统，启动服务器上文件系统客户端，挂载创建的文件系统。

2. CFS产品优势

（1）集成管理

CFS 可以支持 POSIX 文件系统访问语义（例如强数据一致性和文件锁定）。腾讯云计算资源可以通过 NFS v3.0/v4.0 协议来挂载 CFS 文件存储。

CFS 提供控制台界面，让您可以轻松快捷地创建和配置文件系统，节省部署时间和降低维护文件系统工作量。

（2）自动扩展

CFS 可以根据文件容量的大小自动对文件系统存储容量进行扩展，同时不中断请求和应用，确保独享所需的存储资源，同时降低管理工作的时间成本，减轻工作量。

（3）安全可靠

CFS 采用三副本的分布式存储机制、具有极高的可靠性。系统确认数据在三个副本中都完成写入后，才会返回写入成功的响应。后台数据复制机制能在任何一个副本出现故障时，迅速通过数据迁移等方式复制一个新副本，时刻确保有三个副本可用，为用户提供安全放心的数据存储服务。CFS 文件存储数据跨机架存储，可靠性达99.9999999%（9个9）。

CFS 可以严密控制文件系统的访问权限，通过基础网络或 VPC 网络的安全组、并搭配权限组来实现访问权限控制。

（4）成本低廉

CFS 可以动态调整需求容量，而无需提前调配存储。您只需按使用量付费，无最低消费或前期部署、后期运维费用。

多个计算节点可以通过 NFS 协议共享同一个存储空间，而无需重复购买其他的存储服务，也无需考虑缓存。

五、快手案例难点解决方案

1. 选型对比

在上文的客户分析中，客户需求是在腾讯云内网使用，高吞吐（超过1GB/s），且并发访问的计算节点数量达到数千。结合上述存储产品特性表格，CFS 文件存储自然是不二的选择。

2. CFS 解决方案

我们根据业务场景以大文件读为主的特点，通过优化 CFS 的预读策略，实现了热点文件在接入服务器的缓存和预加载；

采用多级 Cache 机制，原始文件在存储服务器上通过 OS Page Cache 进行缓存，多台接入服务器并行拉取数据后缓存在本地；

最终各个 Pod 可以通过vpcgw自动被调度到不同的接入服务器并读取数据，突破了数千客户端并发下单文件的吞吐限制。 

这些客户端连接会被均匀的分散到各个接入服务器上去读取缓存在其上的数据，通过这样分解之后，每个接入服务器上处理的读请求相对就会少很多，这大大减轻了接入服务器的压力以及后端存储服务器的压力，也突破了后端存储限流的瓶颈，最终解决了问题。

3. CFS 解决方案示意图

上图为CFS解决方案示意图：

• 文件 1 通过接入服务器1被 Pod1 读取，并缓存在接入服务器1上；
• Pod2 读取文件1时，它所连接的接入服务器2通过接入服务器1读取CBS上的文件1、并缓存在接入服务器2；
• 以此类推，当 Pod 数量众多时，每台接入服务器上都会有Pod 连接、并从接入服务器1请求数据后缓存在本地；后续每个 Pod 对文件1的请求都可直接从接入层读取。

通过上述方案，CFS 解决了特定场景下单文件大吞吐问题、并发总吞吐峰值达到 6.61GB/s，经受住了多达 1700 个客户端的并发访问，最关键的是以100%的可用性护航了快手春节红包大战并获得了客户的一致好评！

4. 最终结果

此次春节期间活动，全球观众参与快手红包互动累计次数达到639亿，快手春晚直播间累计观看人次7.8亿，创历史新高。

而广告推荐毫无疑问是整个项目中的最重要环节之一，CFS存储通过了预演的层层压测，保障了最新广告模型在最短时间内分发到应用上，关键时期提供了稳定、高可用、高可靠、高性能的服务，护航快手在春节期间交出了完美的答卷。

六、架构师应如何拆解大型项目

最后我想聊一聊，架构师应该如何去拆解一个大型项目？

以分布式文件存储项目为例，对于满足高性能、高可用的分布式文件存储系统来说，市面上不管是开源，还是自研，其实大家的分法都是类似的，基本上可以分为四大部分：管控模块、元数据模块，数据模块和接口模块。

1. 元数据模块

一般主要是用来处理数据的布局和一致性，数据指的就是文件的数据信息。

2. 数据模块

主要是用来处理具体的数据存取和发生故障时的一些数据修复处理，经过一段时间，可能数据的存储在各个磁盘和服务器上是不均匀的，数据均衡模块达到在不同的存储、服务器上实现数据的均衡分布。

3. 接口模块

负责对外提供接口服务，如posix接口服务，NFS接口服务和CIFS接口服务等。

4. 管控模块

可以划分为主控模块、代理模块，接入模块，监控模块。其中主控模块可以分为配置管理模块和高可用模块，代理模块可以分为配置应用模块、心跳模块和流控模块。监控模块又可以分为计费模块、状态收集模块、审计模块、性能统计模块，还有告警模块等。

针对不同的需求，分布式文件存储项目可以拆分成不同的模块，通过拆解后的各模块可以帮助我们更容易理解分布式文件存储的组成原理。同时通过拆解分布式文件存储项目，也可以教会我们如何去设计分布式文件存储。

Q&A

Q：CFS可以在控制台挂载吗？

A：这个是不可以的，如果我们要用CFS，比如我们要用CFS里面的NFS协议，使用的是Linux客户端，那么你只能在Linux客户端安装NFC utils套件，然后通过mount命令来挂载。如果你是Windows客户端的话，你可以用NFSv3协议挂载，也可以用cifs来挂载。

Q：有开源计划吗？

A：目前暂时没有，后续会考虑把我们其中一些做的比较好的项目拿出来开源。

Q：CFS如何进行访问控制？

A：控制其实有两个地方，第1个就是你挂载的时候，在CFS使用创建一个文件系统的时候，最终我们会分配一个vip给用户来帮他挂载使用，这个vip跟用户所在的客户端存在VPC绑定，是关联的。

首先只有通过VPC下的客户端，才能访问vip，那么你通过vip挂载的时候，到了我们后端，我们会去检测你挂载的请求，vip所在的 VPC信息跟你创建文件系统信息是不是对应的？如果一致的话，我们才会让你的挂载请求通过，这是在挂载方面的一个鉴权。

挂载成功之后，我们也会有一个针对IP的限制，通过限制不同的客户端，让有些客户端可以有读的功能，有些可以有写的功能，有些甚至可以把客户端限制成只读。同时当你挂载成功之后，在进行读写的时候，我们NFS可以通过linux的用户组，为用户设置不同的权限。

Q：接入服务器进行大文件缓存是放在本地硬盘？是否可以理解缓存是把存储集群的分布式存储的内容转为本地存储？

A：不是这样的，我们是把文件缓存在我们的内存里，不会把它放在本地硬盘上。

我们并不是把存储集群的分布式存储的内容转为本地存储，我们是把相同文件内容拷贝到各个不同的接入服务器上，这样相当于整个的接入服务器就变成一个大的缓存，这样我们直接在接入服务器的内存就可以直接把客户端所需要的文件内容给它返回给客户端了，而不再需要去实际的从后端读取了。

Q：统计分析是实时的吗？

A：这个肯定不可能是实时的，实时的话对性能影响会非常大，我们的统计是一个异步的过程，最终会以分钟为单位去上报。

Q：cfs和hdfs对比有啥优缺点？

A：hdfs它是一个专用的文件系统。只支持文件的追加写。如果你的需求是一个通用文件的需求，比如要有随机写的一个需求，那肯定是不能用hdfs的。所以我觉得两者最大的区别是，它们面向的点不同，cfs是通用的，你只需要简单的挂载就可以使用，就像访问本地文件系统一样，但hdfs的话就需要根据你的具体场景，可能更多是一些大数据分析，或者在一些特殊的场景中去使用。

Q：刚才的缓存机制，是不是只能针对快手这种“一次写入多次读取”的数据访问模式呢？

A：是的。只是针对快手这种，或者是类似这种一写多读的场景，我们平常在腾讯公网上的CFS架构不是这样的，只是针对快手做了一个特殊的优化。

Q：业务场景跟CFS怎么结合的？

A：这个问题我的理解是怎么使用CFS，其实就是分析用户业务场景，使用的是docker，然后主要就是在他的docker、pod里面去，简单的挂载了我们的cfs，后续他所有业务的那些读取，在他们的应用来看，只是读取它本地上的一个目录而已。

他并不知道他的这些后端经过了网络这么多层的处理，从用户的业务来说，他是不知道的，只知道他在读取一个本地的目录下的一些文件，他是通过这样一种方式跟我们实现结合，然后他们的应用去读这些文件的时候，这些请求会通过从nfs客户端到我们的服务端，会通过我们自己内部的一些转发和处理，然后从缓存也好，从底层存储也好，去把这些文件的数据返回给客户端，返回给用户的应用。

Q：春节红包应对的大文件指的是什么？

A：指的是快手那边的广告推荐模型，他们的模型文件是很大的，是十几GB的大文件，而他们的应用必须要去读这些大文件。

讲师简介

陈宏亮，腾讯云高级工程师。负责腾讯云云文件存储CFS的研发工作，深耕分布式存储方向多年，专注产品便利性、低延时、高吞吐、高IOPS等方面。加入腾讯前，曾负责分布式存储系统的设计研发与项目管控、集群NAS项目，远程复制项目，分布式存储管理系统项目以及对象存储S3项目。