今天谈一个问题,目前cache软件在业界的使用现状。cache系统其实最大的使用场景,还是主要集中在CDN厂商里。

大概在2010年之前,各大CDN厂商基本清一色的使用squid。那时候的squid是绝对的主力。

squid的作为cache领域的鼻祖,正是由于历史的久远,很多近10年左右流行起来的很多系统特性,它本身并不支持。比如sendfile,splice和多核等方面的支持,由于这些特性属于核心架构方面的功能,后期如果想引进的话,需要对squid的核心做大量的修改。对于CDN厂商来说,稳定性是大于性能上的考量的。所以在面临业务增长的性能压力之下,几乎各个厂商内部的cache团队都要去忍痛,咬着牙去做这些大伤元气的改造。

就拿多核的支持来说,因为squid本身是单进程架构,基本上大家的处理方式就是起多实例,所谓的多实例,就是启动多个squid,通过这样的方式让它可以起到多进程的效果。(心好累

当然除了squid之外,还有一个比较新的cache,就是varnish。varnish的作者曾经在自己的博客上批评过squid中很多过时的思想。宣称自己的性能和架构要比squid强大很多。但是作为一个只支持内存的缓存系统(有可以持久化的外围手段),使用的场景是有限的。目前使用varnish的,都是一些小站,或者说热点很集中,缓存总量不大的业务场景。在前几年,我了解到新浪微博有在用它。

随着nginx的崛起,cache领域里也有了它的身影。nginx的proxy_cache功能就是为cache而设计的。关于nginx的cache功能上的一些设计,前面的系列文章里花了不少的篇幅去讲。但是要想作为一个专业的cache,nginx还有很长的路要走。新浪在2010年左右,曾经针对nginx的cache中的不足,专门开发了cache模块来来作为补充,并且开源了,名字就ncache,不过这个项目估计早就死掉了。

2009年,apache trafficserver开源。这个事件,我认为应该是cache领域的重大转折。关于trafficserver,这里有个插曲值得一提。(后面我们简称为ATS)

ATS故事就是一个悲剧。当年03年,雅虎收购了inktomi,当时公司已经彻底把ATS相关产品、代码、资料、人员全部K掉了,资产接手工程师发现在某个角落有个机器,好多土,就问问这机器干嘛的,然后某个还在公司的老员工介绍了一下,雅虎的人还挺实在,就开机看看,发现机器是一个开发测试机器,机器里的系统还能跑,里面有一些不太齐全的代码,然后测试了一下程序,看性能比squid应该好,就把代码入库到雅虎的cvs,cvs tag名字:ts-gold。代码checkin时间,2003年6月20号左右,这就是当年的yts-1.4= i ts-1.4,是ATS的祖宗。后来,ATS发展到09年,1.17版本,砍掉50%代码后,开源出来的yts1.17就是ATS2.0版本。完全是垃圾堆捡回来的,只有一个临时的像是开发测试export出来的代码,没cvs历史,没文档。据猜测,这个机器是因为放角落,不显眼所以没被烧掉,其他能烧的都烧了。

其实有心的话,你去翻开ATS开发团队,其实跟squid是有交集的。很多在squid中不完善的功能,在trafficserver中得到了完善和强化,比如squid中的COSS文件系统,就是个公认的半成品。而在ATS中COSS的思想被发扬光大,其设计和架构让人叹为观止。

正是由于ATS的出现,很多在技术上有远见的公司和CDN厂商开始对ATS的研究和使用。就目前而言,CDN厂商里网宿和帝联已经将ATS用于了生产环境。而很多新兴的小CDN服务商或者云服务提供商也纷纷使用了ATS。蓝汛则在调研后放弃了ATS,还是抱着他们的squid不放。不过近两年,他们开始拿出一部分精力研究nginx。这个属于他们团队更替的结果,这里不做评论。

关于ATS有哪些特性,性能为什么那么强这里就不细说了。以后有机会在讨论。有一点可以提一下,对于HTTP协议的兼容性,ATS是仅次于squid。squid是目前世面上HTTP类服务器里对协议支持最全面的。nginx大概只有50%。

QQ截图20150618114600.jpg

 

跳出CDN厂商的圈子,我们看看在互联网公司内,cache软件的状况。大概在2010年之前,淘宝内部的cache也是主要以squid为主,后来新团队在调研过ATS之后,开始将其在cache业务上推广,大概花了3年的时间,ATS慢慢变成了主力,并且在2013年的双11期间挑起了大梁。不过这两年,他们自己开发的Swift缓存系统逐渐成形(这里的swift不是openstack的组件,不要混了),并且开始逐步替代ATS。

 

那么在阿里放弃ATS之后,其他的大公司的使用者,据我了解就是京东,新浪微博这些了。对了,小米也在用ATS。

 

国外的情况来看,ATS的使用目前也不是太多,比较大的有akamai,yahoo,linkedin这些了。据说google也在用哦。ATS之所以没有普及开来,跟它本身的复杂性是有直接关系的。某人曾说过,如果nginx是初中生的话,ATS就可以是博士生。(逃

 

不过这几年,服务器领域风头最劲的,还要属nginx。特别是国内范围内nginx的火爆场面,真是让人羡慕。这跟阿里的不遗余力的推广有很大关系。在2010年左右,网上能找到的关于nginx分析得比较好的博客,作者基本都是阿里的,或者后来去了阿里。这里面必须要提到的就是章亦春(agentzh)。他几乎是靠一己之力,将nginx推上了一个新高度。nginx lua模块的诞生可以说是革命性的。

 

现在使用nginx的公司,几乎都在使用nginx lua。在WAF领域,nginx lua的出现,在技术实现上来说,完全变成了傻瓜式。

 

由于lua天生跟c,c++的密切性,使得连ATS都支持了lua模块。所以很多公司的后端服务的架构也随之发生了改变。他们开始讲纯粹的业务逻辑剥离出来,用nginx lua来实现,放在前端。这样原来必须在cache里面用c或者c++写业务逻辑的苦逼状况得以极大的改善。

 

所以nginx+ats,nginx+squid的架构开始出现,并得到了广泛过的应用。而阿里现在的架构也是这样的:

QQ截图20150618114730.jpg

 

 

在上图中我们可以看到前面的nginx(也即是tengine)充当业务处理和调度,后面的cache(swfit)做缓存。这样的架构,让业务开发变得很容易,而且很高效。nginx+lua可以轻松搞定。

 

那么问题来了,这样的架构相比较直接用c/c++在cache写业务处理,性能上肯定会降低,那么就需要评估下性能降低的情况,如果太多,那么即使是nginx+lua换来了开发和维护的低成本,可能也是难以接受的。我专门针对这两种架构,进行了性能测试,cache使用的是ATS。

 

单纯使用ATS:

QQ截图20150618114813.jpg

 

Nginx+ATS: 

 

QQ截图20150618114844.jpg

 

  • con: 并发连接数。并发连接数,单进程单cpu处理能力取决于CPU与测试场景,请酌情设置,推荐小于9999

  • new: 每秒新建连接数。这个参数取决于并发连接数量与长连接效率。

  • ops: 每秒请求数。也作qps,是比较体现服务器性能的关键指标。

  • 1byte:首字节平均响应时间。这个是体现整体转发效率的关键指标。

  • lat: 完成请求整体响应时间(收到最后一个字节)。cache系统性能关键指标。

  • bytes/per:每秒字节流量/每秒每连接流量

  • total:服务器端总请求的字节数

  • time:测试时间(秒)

 

通过数据对比我们可以看到,nginx+ats的性能较纯ats,要降低大概5%,这个是完全可以接受的。注意这里的nginx跟ats是放在一台服务上的,如果分开不同的机器,那就得不偿失了,不仅latency增加,机器的数量也随之增加。

via。http://blog.csdn.net/charleslei/article/details/50879908