今天谈一个问题，目前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%。
跳出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的架构开始出现，并得到了广泛过的应用。而阿里现在的架构也是这样的：
在上图中我们可以看到前面的nginx（也即是tengine）充当业务处理和调度，后面的cache（swfit）做缓存。这样的架构，让业务开发变得很容易，而且很高效。nginx+lua可以轻松搞定。
那么问题来了，这样的架构相比较直接用c/c++在cache写业务处理，性能上肯定会降低，那么就需要评估下性能降低的情况，如果太多，那么即使是nginx+lua换来了开发和维护的低成本，可能也是难以接受的。我专门针对这两种架构，进行了性能测试，cache使用的是ATS。
单纯使用ATS:
Nginx+ATS:
-
con: 并发连接数。并发连接数，单进程单cpu处理能力取决于CPU与测试场景，请酌情设置，推荐小于9999
-
new: 每秒新建连接数。这个参数取决于并发连接数量与长连接效率。
-
ops: 每秒请求数。也作qps，是比较体现服务器性能的关键指标。
-
1byte：首字节平均响应时间。这个是体现整体转发效率的关键指标。
-
lat: 完成请求整体响应时间（收到最后一个字节）。cache系统性能关键指标。
-
bytes/per：每秒字节流量/每秒每连接流量
-
total：服务器端总请求的字节数
-
time：测试时间（秒）
通过数据对比我们可以看到，nginx+ats的性能较纯ats，要降低大概5%，这个是完全可以接受的。注意这里的nginx跟ats是放在一台服务上的，如果分开不同的机器，那就得不偿失了，不仅latency增加，机器的数量也随之增加。