最近小组在做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:人与人之间的配合,态度是至关重要的.

建议继续学习：

1. XML/RSS的CDATA区段    (阅读：2020)
2. RSS Feed 迁移的方案    (阅读：1934)