Nginx + Squid访问集群环境下动态生成的文件的可行性研究

最近项目中遇到需求，分布式环境，N个对等服务，其中一个服务动态产生的文件，并产生一个访问url，url的域名是N个服务的负载均衡地址，用户在浏览器或客户端希望通过这个url访问到这个文件。 由于是集群环境，且文档是从其中一个服务中产生的，其他对等服务中没有这些文件，因此，访问这个url，就存在负载均衡不能分发到文件生产者服务中，存在访问失败的风险。

为了解决这个问题，考虑研究下Nginx + squid是否可以解决这个问题，初步设想结构图：

如结构图中，动态资源，由Nginx直接转发到Realserver，而静态资源文件，如jpg，png，js等，转发到squid，由squid负责向realserver访问。

因为squid是具有将访问某个url的静态资源缓存到本地的能力，如果squid可以支持遍历访问所有realserver，那么，任意一个realserver产生文件，只需要保存在本地，构建统一的负载均衡地址，客户端测访问来时，通过squid时，交由squid负责向realserver中搜寻具体文件地址，如果请求realserver1中没有文件，再向realserver2中请求，遍历完所有realserver后，请求到文件，再将静态文件缓存到squid本地，下次再有相同url请求时，squid直接返回。

有这种想法，目的就是想降低realserver的实现复杂度，从而降低整个产品架构的复杂程度。

不管是否可行，先搞起来测试下再说:

第一步，安装nginx 和squid，具体步骤网上很多，这里不赘述。

第二步，nginx配置

upstream squid_domain{ server 127.0.0.1:3128;    #squid和nginx部署在一起，直接配置127.0.0.1}upstream realserver_domain{server 192.168.4.180:8001;  #realserver1server 192.168.4.181:8001;  #realserver2server 192.168.4.182:8001;  #realserver3}#发向/wardemo/images的请求，路由到squid_domianlocation /wardemo/images {proxy_pass http://squid_domain;proxy_redirect off;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;}#发向/wardemo的请求，路由到realserver_domainlocation /wardemo {proxy_pass http://realserver_domain; proxy_redirect off; proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;}

</pre><pre>

第三步，squid配置

http_port 3128 accel vhost vportnonhierarchical_direct offcache_peer 192.168.4.180 parent 8080 0 no-query originserver name=acache_peer 192.168.4.181 parent 8001 0 no-query originserver name=bcache_peer 192.168.4.182 parent 8001 0 no-query originserver name=ccache_peer_domain a 192.168.160.79cache_peer_domain b 192.168.160.79cache_peer_domain c 192.168.160.79

realserver1产生的文件1.jpg存储在本地，产生的rul地址是：http://192.168.160.79/wardemo/images/1.jpg，当用户请求时，会映射到squid中，此时希望squid能便利访问3个cache_peer，从而知道获取到1.jpg，及时第一次请求到realserver2中没有1.jpg，squid也能再次请求其他realserver，获取到图片。

实际测试证明，squid不会便利请求下游的realserver，仅仅会根据cache_peer的配置顺序或权重访问。只有当其中一个realserver宕机，才会请求其他节点。

测试失败，没有达到预期效果，但整个过程也记录下来，

近期又研究了下FastDFS，支持分布式文件存储，貌似可以解决我的问题，等又研究结果。后面再写一篇关于FastDFS的。