11 14
ATS缓存组件使用总结

一、简介

Apache Traffic Server基本可以用一句话概括:它不仅是HTTP代理服务器, 还是HTTP缓存服务器,且可以缓存任何字节流数据。

二、使用情况

由于是做电商,为了满足日常业务的发展,最初的nginx-proxycache的方式已经不能满足我们的大并发量而且大流量对象的缓存需要。这个时候我调研过squid、varnish等缓存代理,最后基于同行的使用报告和自己搭建使用一段时间后,最终我们就决定采用ATS作为缓存中心的核心层。具体的原因有以下几点:

  • URL Rewrite 功能可以满足线上需求;

  • 支持https;

  • ATS提供TS-Lua;

  • 支持日志自定义格式;

  • 支持后端检测;

  • 插件化支持

三、ATS缓存服务架构

3.1、集群结构

先简单说明下我们采用的部署方案,如下图:

ats

我们采用两级缓存层作为服务提供方案:边缘节点+中心节点。边缘节点主要负责反向代理和一级缓存;中心节点负责二级缓存和负载到HA(回源入口)

3.2、内部cache架构

缓存对象的概念

一个字节流被缓存住时(还有相关的HTTP协议头)我们称之为缓存中的一个对象。每个对象可以通过全局唯一的缓存key的来定位,我们也称之为KV对象。

详细参考: Cache Architecture

四、运维方案

常用命令

1、安装

前期需要安装相关依赖:

sudo yum install -y pkgconfig libtool gcc gcc-c++ make openssl openssl-devel tcl tcl-devel pcre libcap flex hwloc lua curses curl

安装完成后,进行编译

$ cd /apps/demo/trafficserver-${VERSION}

$ ./configure --with-user=apps --with-group=apps --prefix=/apps/demo/trafficserver --sysconfdir=/apps/conf/trafficserver --localstatedir=/apps/dbdat/trafficserver --enable-debug --enable-example-plugins --enable-experimental-plugins --enable-hwloc

$ make && make install

2、配置集群

访问边缘节点,资源请求不命中,会 remap 到 parent ats 节点去请求相关的资源。

1)如果是边缘节点,修改 /apps/conf/trafficserver/parent.config,增加以下配置:(ip是中心节点的ip,下面是随意写)

dest_domain=. method=get  parent="10.11.10.1:80;10.11.10.2:80;10.11.10.3:80;10.11.10.4:80"  round_robin=consistent_hash

并修改 /apps/conf/trafficserver/records.config 配置

CONFIG proxy.config.url_remap.pristine_host_hdr INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
CONFIG proxy.config.http.insert_request_via_str INT 1
CONFIG proxy.config.http.insert_response_via_str INT 2

2)如果是中心节点,修改 /apps/conf/trafficserver/remap.config 配置

反向配置并增加balance负载策略 remap.config文件参考配置如下:(ip是ha的ip或源站ip,下面是随意写)

map http://a.testpic.com/ http://a.testpic.com/  @plugin=/apps/demo/trafficserver/libexec/trafficserver/balancer.so @pparam=--policy=hash,url @pparam=10.10.10.1 @pparam=10.10.10.2  @pparam=10.10.10.3

并且修改 /apps/conf/trafficserver/records.config 配置

CONFIG proxy.config.url_remap.pristine_host_hdr INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 0
CONFIG proxy.config.http.insert_request_via_str INT 1
CONFIG proxy.config.http.insert_response_via_str INT 2

3、关闭与启动

$ /apps/demo/trafficserver/bin/trafficserver stop
$ /apps/demo/trafficserver/bin/trafficserver start

4、日志查看

$ /apps/demo/trafficserver/bin/traffic_logcat -f 日志文件路径

5、配置更新

$ /apps/demo/trafficserver/bin/traffic_ctl config reload

6、数据清理

$ /apps/demo/trafficserver/bin/traffic_server -Cclear

7、状态监控

修改 plugins.config,增加以下配置:

stats_over_http.so --integer-counters --wrap-counters

通过下面命令进行获取

curl http://ip:port/_stats

关注点与调控

cache是整个服务的核心,ats缓存架构核心理念是缓存布局的高效管理

ats的缓存布局管理只有分为内存和磁盘读写控制,详细架构设计请参考官网的开发指南

1、in-memory(RAM)

配置入口:/apps/conf/trafficserver/records.config

说明:设置主存大小

CONFIG proxy.config.cache.ram_cache.size INT 26843545600 # 移动图片缓存中心边缘节点设置RAM最大为25G
CONFIG proxy.config.cache.ram_cache_cutoff INT 26843545600
CONFIG proxy.config.cache.limits.http.max_alts INT 5
CONFIG proxy.config.cache.max_doc_size INT 0 #不限制缓存object 大小
CONFIG proxy.config.cache.min_average_object_size INT 8000

2、on-disk

配置入口:/apps/conf/trafficserver/storage.config

说明:设置磁盘存储缓存的最大空间,当存储上限达到此值时,存储空间不会再增长,ats开始根据clufs算法排走部分缓存数据

/apps/dbdat/trafficserver/trafficserver 400G

3、开启UI

配置入口:/apps/conf/trafficserver/records.config

CONFIG proxy.config.http_ui_enabled INT 3
说明:
0 - 禁止所以内部UI访问
1 - 只允许cache相关的UI访问
2 - 只允许状态stats相关的UI访问
3 - 开放所有功能UI的访问 

remap.config设置反向代理规则

配置入口:/apps/conf/trafficserver/remap.config

map http://ats-node.com/cache     http://{cache} 
map http://ats-node.com/cache-internal     http://{cache-internal} 
map http://ats-node.com/stat     http://{stat}
map http://ats-node.com/test     http://{test} 
map http://ats-node.com/hostdb     http://{hostdb} 
map http://ats-node.com/net     http://{net} 
map http://ats-node.com/http     http://{http}

通过浏览器访问 http://ats-node.com/cache/ 即可

集群检测方案

任何分布式服务,CAP不能同时实现,特别目前以两级缓存模型实现的ATS结构更是如此。由于边缘节点依赖中心节点,ats边缘节点使用URL一致性哈希把请求打到中心节点的时候,如果中心节点挂掉,ats节点本身会做rehash,但rehash的次数是有限制的,极端情况下,当所有的中心节点不可用时,我们希望ats节点能直接回源操作,保障可用性.

ats中心节点回源策略是透过URL哈希方式负载到haproxy上的,同理,如果ha节点挂掉,会直接影响缓存服务,请求无法穿透到源站。 所以我们需要一个工具除了能监测依赖节点的健康情况外,还需要做容错和故障恢复等功能。

有见及此,我开发了一个 ats_check (https://github.com/domac/ats_check) 工具。

服务场景如下:

  • 边缘节点依赖多个中心节点,当出现某中心节点服务不可用时,ats_check会自动发现并迅速调整 ATS 的parent.config的配置

  • 当边缘节点发现其所有中心节点都不可用时,ats_check 会进一步调整 records.config 关闭parent proxy功能,并自动调整 remap , 让请求能直接通过balance,回到源站

  • 中心节点本身发现负责回源的Haproxy节点不可用时,ats_check会修改 remap,确保回源有效,提高鲁棒性

五、调优与改进

  • 定制化插件

参考

ATS官方文档

varnish/squid/nginx cache有什么不同

nginx ats squid varnish使用场景对比介绍