西西河

主题:【半原创】Flickr 网站架构研究(1) -- 西电鲁丁

共:💬69 🌺366 新:
全看分页树展 · 主题 跟帖
家园 先送花再学习

每个数据中心平时的负载只是其可最大负载的50%,这样在"Pair"中的一个数据中心因为停电,地震等灾难或必要维护而停止服务时,另一个数据中心仍然能够处理全部的访问。

这部分看起来有一些浪费?现在是否可以使用云来替代?还是云在某些方面满足不了flickr的要求?

如何避免”多次缓存“,即我们希望同一份文件只缓存一次,而不是在多个Squid中保留多份COPY,以最大限度的利用缓存空间。解决这个问题的办法是在 Squid服务器集群之前放置Layer 7的Load Balancer。相对于传统的基于IP地址加PORT端口的Layer 4的Load Balancer,Layer 7的Load Balancer可以根据规则,对应用层的信息,如HTTP的Header,URL,Cookie Name等进行哈希或CRC计算,从而确保同一URL的请求总是指向后台集群中的同一台Squid服务器。

原来flickr是用这样的策略做负载均衡的,有意思,这样确实能保障squid缓存的内容不同,后面的图表也能看到缓存命中率不错,但是这样做从另一个角度看人为增加了群集节点的差异性,在failover和管理方面会比较麻烦,例如,如果负责A内容的squid节点当掉,在添加进新的节点或者转移请求到其他节点之前,A内容缓存命中率为0,加入新节点或者转移到其他节点之后,缓存命中率也有一个上升的过程,也就是说,有降低整体性能的可能。或者说,在flickr的负载平衡策略里面还有什么花样?让squid节点缓存内容适度形成交集?如果是,那么交集的决定策略又是什么?

做个大站,费神的事情真不少。。。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河