最近小组在做rss的一些调整,从中也发现了一些技术层面和非技术层面的问题:
技术层面:
目前的问题:
1:我们是通过前端缓存squid来提供rss服务的,rss服务抓取商一般是通过no-cache和页面url加随机数进行访问的.
而这也正是squid权限控制的一个"弊端",导致90%的请求都直接访问squid的后端,也就是说squid没有起到缓存的作用.
2:Rss地址过多(历史原因造成的),导致cache命中率过多.
3:由于rss服务特性和web服务特性的不一样,也因为cache命中率不高的原因,rss Squid的后端是专门的一组server.
解决的办法:
1:解决no-cache 穿透的问题,通过设置refresh_pattern -i .xml$ 11440 50% 22880 ignore-reload。
2:解决随机数访问url的问题:
squid的前端是nginx,主要作用是squid的分组hash和规则匹配.
而过滤url的随机数则需要在nginx上做(squid上做应该也是可以的).
location /rss/
{
if ( $request_method = POST ){
rewrite ^ $scheme://$host$uri redirect;
}
rewrite (.*) $1? break;
}
3:小镇挖掘比较深的一个问题是:增加随机数后会不会将同一份数据缓存在多个squid上,这样的话即使上面的规则匹配了，还是毫无用处的。
我们是通过url的完整地址做squid hash的,通过下面的配置解决这问题.
if ($request_uri ~* "^(/rss/.*\\.xml)" )
{
set $request_hash_key $1;
}
4:进一步挖掘，博客的前端squid在多个idc都是部署的,这样也许一个url的请求（假如各地都访问的话），则会造成对后端的访问。
修改配置比较简单，将各个idc的squid指向同一组squid即可，但从通用性考虑，这次可以先不考虑。
非技术层面：
1:上述的配置也许很简单，但通过尝试，可能会发现了一些大问题，也会挖掘的更身。
2:做一件事情很简单,重要的是持续的做下去,做到极限.
3:人与人之间的配合,态度是至关重要的.