专栏首页吴锐的专栏深入浅出腾讯云 CDN:缓存篇
原创

深入浅出腾讯云 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 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 百年百图の中国(1900-1999):另类python爬虫和PIL拼图

    标题有点长,也有点怪。前半部分文艺向,后半部分python技术向。目的就是用PIL库得到100张图的拼图(成果图见文末)。

    古柳_DesertsX
  • 软件测试与代码安全详解

    本人学习软件测试收获不少,于是便记录下来自己的思路与知识总结,重温自己的探索之路。

    达达前端
  • 又一批长事务,P0故障谁来背锅?

    面试时,大家可能都会碰到关于事务相关的问题,升级版的可能是分布式事务的问题。在互联网行业中,一句马马虎虎的补偿事务就能蒙混过关,毕竟都是些短小精悍的接口。 但...

    xjjdog
  • 我说分布式事务之TCC

    接触分布式相关的开发已经有一段时间了,自然绕不开分布式事务。从本文开始,我将带领大家了解常见的分布式事务的解决方案,深入原理,浅出实践,让我们在今后的开发中对分...

    程序猿DD
  • 专访 | 语音助手的涅槃关头,我们应该完全抛弃屏幕还是选择“语音+图形界面”?

    AI科技评论按:距离苹果Siri的推出已经快6年了,期间很多智能手机厂商也纷纷将语音助手列为卖点之一,但是其使用率一直不高,究其原因,还是语音助手的功能有限。不...

    AI科技评论
  • 叮~这有一份腾讯安全重保“全垒打”成绩单

    腾讯安全重保全栈解决方案,从企业和机构自身所处行业及业务特性出发进行整体安全咨询,量身定制所需安全服务,并灵活结合安全防护产品体系发挥最佳效果。

    腾讯安全
  • 中国博士生提出最先进AI训练优化器,收敛快精度高,网友亲测:Adam可以退休了

    但是鱼和熊掌不可兼得。Adam、RMSProp这些算法虽然收敛速度很快,当往往会掉入局部最优解的“陷阱”;原始的SGD方法虽然能收敛到更好的结果,但是训练速度太...

    算法工程师之路
  • 中国博士生提出最先进AI训练优化器,收敛快精度高,网友亲测:Adam可以退休了

    但是鱼和熊掌不可兼得。Adam、RMSProp这些算法虽然收敛速度很快,当往往会掉入局部最优解的“陷阱”;原始的SGD方法虽然能收敛到更好的结果,但是训练速度太...

    代码医生工作室
  • python 调用cmd,不显示cmd黑

           在一个子shell中运行command命令,并返回command命令执行完毕后的退出状态。这实际上是使用C标准库函数system()实现的。这个函...

    py3study
  • Python练习3:判断学生成绩等级

    #判断学生成绩等级,等级分为A~E,其中90分以上为A,80~89为B,70~79为C,60~69为D,60分一下为E

    py3study

扫码关注云+社区

领取腾讯云代金券