深入浅出腾讯云 CDN:缓存篇

作者介绍:吴锐,开源爱好者。曾在阿里巴巴搬砖,目前就职于腾讯担任高级工程师,专注于创造高效代码。

1. 引言

互联网的发展为CDN的发展带来了巨大的机遇。不论是视频点播,直播或者VR技术都需要CDN做为传输内容的载体。老牌CDN服务商网宿2016年上半年CDN业务的营收比上年同期增长达到76.04%。

但是CDN作为云基础服务中关键的一环,一直是各个云服务器提供商的必争之地。腾讯云如果需要在竞争中取得一席之地,就需要能够从容应对云上这些复杂的内容进行处理。原有CDN服务器的存储引擎在处理视频文件,以及复杂的HTTP协议内容上出现了瓶颈,改造迫在眉睫。

2. 问题

对于视频这种大文件,原有SSD盘的存储容量无法保证热点文件存储在缓存中,因此SATA盘这种大容量磁盘被应用到了CDN边缘节点中用来缓存视频大文件,以保证CDN边缘节点的命中率。

但是原有CDN服务器存储引擎在SATA盘上的表现并不理想,如下图所示,在TS6上只能跑600Mbps流量,并且IO也处于比较高的水位,这限制CDN节点的服务能力。

图1 DiskTank在TS6上的处理能力

另外,在某些业务场景下服务器会导致CPU毛刺的出现,定位发现是原有存储引擎的一些限制以及处理流程的问题导致的。不能挡在业务前进的路上,存储引擎的改造势在必行。老的存储引擎为DiskTank,新改造的存储引擎因为历史原因命名为DiskTank3。下文就将老存储引擎成为DiskTank,新引擎成为DiskTank3。

图2 DiskTank的CPU毛刺

3. 硬件层

首先我们考虑是否完全充分利用了磁盘的性能,什么读写方式才能将磁盘的性能最大化。在调研了磁盘相关的构造后发现,经过对齐之后的写操作能够带来巨大的性能优化。

不管SSD盘或者SATA盘都有最小的操作单位,可能是512B,4KB,8KB。如果读写过程中不进行对齐,底层的硬件或者驱动就需要替应用层来做对齐操作,并将一次读写操作分裂为多次读写操作。

如下图是在同一台TS8服务器上进行测试的结果。每次操作块大小为130K的吞吐能力仅为128K的21.65%。每次操作的块大小变大了,性能反而出现了明显的下降。

这是十分反直觉的,并且也说明了对齐的重要性。因此DiskTank3的第一个优化就是将写入的数据都进行Page对齐。目前不论SSD盘或者SATA盘的Page都为4KB的倍数,因此DiskTank3写入数据时按照4KB进行对齐。当然,这个参数是可调,方便后续调整。

图3 128KB块大小吞吐量测试

图4 130KB块大小吞吐量测试

4. 系统层

接下从系统层开始考虑从系统层面开始优化。

第一,在运营过程中发现在内存吃紧时,即使Page Cache中还有空闲内存时,内核会使用Swap的内存,或者是回收内存带来额外的CPU开销等问题;

第二,文件系统的元数据也会有IO的开销。而CDN的存储引擎自己进行缓存数据的管理,完全可以使用裸盘进行读写。消灭文件系统的开销。如下图所示,DiskTank3中支持越过文件系统直接使用裸盘读写,来完全解放磁盘IO性能。

图5 IO处理流程

直接使用裸盘带来的另一个好处是可以使用内核提供的异步IO功能。异步IO可以解放CPU,进一步提高服务器的处理能力。目前DiskTank3已经支持异步IO。但是异步IO在IO没有完成之前,写入缓存会占用内存空间。需要对这部分内存进行限制,防止消耗过多内存影响服务器正常处理。

5. 应用层

最后再来考虑从应用层面优化。主要优化点有:

5.1 文件分片存储

DiskTank存储文件时候使用连续的存储空间。当需要淘汰老文件,挪出空间来存储新文件时,就需要将整个老文件从缓存中删除。对小文件这并没有什么问题。但是如果为了存储一个4KB的小文件而将一个1GB的文件从缓存中删除,这明显得不偿失的。

因此,在DiskTank3中,所有大文件都会被分成一个个1M的数据分片进行存储。这样在淘汰时也只需要淘汰一个1M的数据分片,在需要时也只需要拉取一个1M的数据分片即可。这解决了DiskTank在淘汰大文件时引起大量回源流量的问题。

同时,分片存储也带来了另外一个好处,就是CDN的缓存可以支持变长文件。这在客户源站只支持HTTP中的分块传输(Chunked transfer encoding),这种不知道文件大小长度的情况下就十分有用。

DiskTank由于在存储之前需要知道文件的确切大小,因此之前的做法是先在内存中接受并缓存数据,等到接受完毕确定文件大小后,再存储到缓存中。DiskTank3可以将数据直接写到缓存中,降低了内存和CPU开销。

图6 DiskTank存储与淘汰方式

图7 DiskTank3存储与淘汰方式

5.2 元数据与文件数据隔离

另外在运营中发现,在某些场景下,元数据频繁的被读写。导致元数据的读写IO开销变得十分明显。而元数据与正常文件数据是存放在同一块磁盘中,这影响了正常文件数据的存取。

因此,在DiskTank3中可以将元数据与文件数据分开存储。元数据可以存储在IO能力较强的SSD盘中,而文件数据则单独存储在数据盘中。在小文件场景下,甚至可以将元数据存放在内存文件系统tmpfs中,完全规避元数据的IO开销。

5.3 小文件忽略缓存头部

第三个优化点在于提高小文件的存储效率。CDN在缓存文件的同时会将和文件相关的一些信息,如HTTP头部,Mtime和Host等信息,作为头部存储在缓存文件的开头。这部分数据大小为几KB。在小文件业务,大量文件的长度也就为几KB,缓存头部就占据了将近一半的存储空间。部分业务并不需要这些缓存信息,因此可以将这部分缓存头部省略,进一步提高存储利用率。

5.4 单盘容灾

最后,运营海量服务器的场景下,坏盘变得频繁。

如果运维收到告警后,人肉处理就需要比较长的响应时间,甚至影响服务器上业务的运行。新版本的DiskTank3支持将坏盘自动从缓存中剔除坏盘,坏盘问题不会中断业务的正常运行。坏盘在被剔除之后,缓存会在剩余的其他磁盘上重新Hash分布,不影响正常文件存取。

6. 总结

在进行优化之后,将老版本的DiskTank与新版本的DiskTank3在同机房选择了两台机器,使用相同业务进行压测对比。流量提升40%,负载降低13%,消耗降低31% 。

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

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

编辑于

吴锐的专栏

1 篇文章1 人订阅

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏黑白安全

黑客技术?没你想象的那么难!——dns劫持篇

在网络中,机器之间只认识IP地址,机器之间最终都要通过IP来互相访问。但是为了方便记忆,可以为IP地址设置一个对应的域名,通过访问域名,就可以找到对应IP地址的...

2613
来自专栏杨建荣的学习笔记

MySQL DBA工作突围的一个入口-慢日志

在MySQL中,对于性能问题诊断,最开始的时候总是感觉有些束手无策,如果一个人问你,MySQL数据库响应慢了,该怎么办,如果数据库服务器CPU 100%了该怎么...

832
来自专栏Java架构师历程

优步微服务架构 – 构建和部署应用程序

从我之前的博客,你必须已经对微服务架构有了基本的了解。在本博客中,您将深入了解架构概念并使用优步案例研究来实现它们。

1123
来自专栏后端技术探索

携程异步消息系统实践

今天会跟大家分享一下我们在携程,现在应该是正在推广的一个新的消息系统,主要会偏重于讲一些架构和实现方面的内容。目前我在携程大概一年多都在做新的消息系统Herme...

1022
来自专栏ImportSource

故障驱动的微服务架构设计

此文背景: 之所以发布此文,是有一个直接的原因,就是我们之前在线上遇到了一个使用timeout来判断是否失败的案例,这是真实的,结果就是效果很不好。看了本文中介...

4027
来自专栏大数据和云计算技术

资源管理框架(mesos/YARN/coraca/Torca/Omega)分析

1 资源调度的目标和价值 1.1 子系统高效调度 任务之间资源隔离,减少争抢。 任务分配调度时结合资源分配,各个任务分配合理的资源,充分利用系统资源,减少资源利...

3688
来自专栏云计算D1net

云应用:混合云需要混合网络来支撑

在经过一番艰苦努力的之后,我最终调试解决了一个非常棘手的混合云网络问题。 虚拟私有云(VPC)提供了一个包含免费虚拟机(VM)使用时间的培训项目,学生可以跟随一...

2814
来自专栏云计算D1net

如何应对混合云网络的复杂性?

在经过一番艰苦努力的之后,我最终调试解决了一个非常棘手的混合云网络问题。 虚拟私有云(VPC)提供了一个包含免费虚拟机(VM)使用时间的培训项目,学生可以跟随一...

3416
来自专栏即时通讯技术

IPv6技术详解:基本概念、应用现状、技术实践(下篇)

在上篇《IPv6技术详解:基本概念、应用现状、技术实践(上篇)》,我们讲解了IPV6的基本概念。

943
来自专栏WeTest质量开放平台团队的专栏

如何应对苹果app 的ipv6 时代?腾讯专家教您进行环境改造

WWDC2015苹果宣布在ios9支持纯IPv6的网络服务,并且要求2016年提交到app store的应用必须兼容纯IPv6的网络,要求适配的系统版本是ios...

592

扫码关注云+社区