QunarCache的应用
CDN（content delivery network）全称是内容分发网络。
Internet 超级快递员（图片、文本、音乐、电影、消费订单、微博。。。）
1、防御入侵，抵御攻击，保证服务质量
2、用户体验（控制时延）
CDN 就是尽可能的减少资源在转发、传输、链路抖动等情况下访问时延，确保用户快速准确的访问效果。
3、省时、省力、省钱
大家都知道 CDN 其实就是架在用户身边的一层代理，真正提供服务的是最终访问到的源站。
那如何来预防 CDN 崩溃导致的大流量回源呢？
1、多家 CDN 实现资源多节点、多备份、多保障
2、通过智能 DNS 实现不同运营商的 DNS 解析控制，保证访问分流到各家待分配的 CDN
3、多家之间对比服务（服务质量、售后、价格等等）
1、CDN 后面增加一层自建 Cache，保证源站的安全
2、多区域部署，实现专属线路的网络优势和保护
这样的架构到底为我们实现了怎么样的保护呢？
一家 CDN 挂掉导致大流量涌入我们的 Cache 集群，Cache 逐步增长的压力正在消化这部分突发流量，而保护了我们的源站免于突发和大流量带来的压力。
Squid、Varnish、ATS（Apache Traffic Server）、Nginx
名称 | 江湖地位 | 所属门派 | 江湖威望 |
Squid | 历史悠久，成熟，老套 | 资源量较大，并发不高 | 3星：技术成熟专业，多实例实现 |
Varnish | 初出茅庐知天下三分 | 热点集中，缓存总量不大 | 2星：性能高，但不适合我们 |
ATS | 异族高手，高深莫测 | 全能 | 2星：功能强大，性能好，维护成本高，有点难 |
Nginx | 十全大补丹，剑走偏锋 | 全能 | 2星：不够成熟，维护成本较高 |
按需而行
1、我们的资源总量大、热点不集中、缓存更新频繁......
2、选型 Nginx + Squid
该模式有效的达到内存的的横向扩展，避免了资源重复消耗及缓存数据的查询时间，但只适合小集群。
该模式即转嫁了 Cache 的查询压力，又实现了 Cache 容量的横向扩展，随着我们的集群扩大，逐步取代原有的模式。
相比原有模式，该结构起到的作用。
用过 Squid 的同学都知道，Squid 虽然优点很多，但却是个性能短版的单进程服务，所以我们在原有基础上通过增加 Squid 进程来实现性能的提升。
那性能上有多大的提升呢？
了解用户的访问体验（最后的一公里）
监控 QunarCache 的服务状况
需求不同，侧重点区分
充分利用现有硬件资源
区分集群和基础硬件的差异
统一操作实现快速部署
收集 CDN 日志，并进一步分析
● 访问效果
● 性能数据监控
● 取样报警
完善 CDN 访问监控，结合 QunarDNS 实现自助故障切换