深入浅出腾讯云 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 条评论
登录 后参与评论

相关文章

来自专栏xingoo, 一个梦想做发明家的程序员

如何构建高扩展性网站?

本篇通过阅读《高扩展性网站的50条原则》,总结出以下内容。 一方面博主没有实际的架构经验,另一方面知识面也不够宽阔,所以只能系统的总结书中的要点,并根据自己...

1935
来自专栏企鹅号快讯

实用的国产优秀开源中间件

在系统软件之中,操作系统、数据库、中间件的三驾马车,中间件是最神秘的,而且是一个专业化非常强的细分产业。中间件技术主要用来支撑分布式软件的开发,在大型分布式软件...

19810
来自专栏CSDN技术头条

【问底】徐汉彬:亿级Web系统搭建——单机到分布式集群

大规模流量的网站架构,从来都是慢慢“成长”而来。而这个过程中,会遇到很多问题,在不断解决问题的过程中,Web系统变得越来越大。并且,新的挑战又往往出现在旧的解决...

20210
来自专栏美团技术团队

Logan:美团点评移动端基础日志库揭秘

背景 对于移动应用来说,日志库是必不可少的基础设施,美团点评集团旗下移动应用每天产生的众多种类的日志数据已经达到几十亿量级。为了解决日志模块普遍存在的效率、安全...

47612
来自专栏开源项目

实用的国产优秀开源中间件 | 码云周刊第 52 期

在系统软件之中,操作系统、数据库、中间件的三驾马车,中间件是最神秘的,而且是一个专业化非常强的细分产业。中间件技术主要用来支撑分布式软件的开发,在大型分布式软件...

3698
来自专栏逸鹏说道

亿级Web系统搭建:单机到分布式集群

当一个Web系统从日访问量10万逐步增长到1000万,甚至超过1亿的过程中,Web系统承受的压力会越来越大,在这个过程中,我们会遇到很多的问题。为了解决这些性能...

3327
来自专栏逸鹏说道

浅谈web网站架构演变过程

前言   我们以javaweb为例,来搭建一个简单的电商系统,看看这个系统可以如何一步步演变。   该系统具备的功能: 用户模块:用户注册和管理 商品模块:商品...

1.6K60
来自专栏Java进阶干货

成为一名Java高级架构师你应该要学习的技术

973
来自专栏Java职业技术分享

为什么不要把ZooKeeper用于服务发现?

        但在云环境中,面对设备及网络故障时的恢复能力是需要重点考虑的问题。因此,将应用部署在云上,就必须要预见到硬件故障、网络延迟以及网络分区等问题,进...

500
来自专栏北京马哥教育

如何构建高扩展性网站?

本篇通过阅读《高扩展性网站的50条原则》,总结出以下内容。   一方面博主没有实际的架构经验,另一方面知识面也不够宽阔,所以只能系统的总结书中的要点,并根据自...

2534

扫码关注云+社区