主题：【半原创】Flickr 网站架构研究（1） -- 西电鲁丁

实际上没有什么太大花头。我用berkeleydb做过一个类似的server，每秒每台机器的平均请求在600左右。每次请求数据传输在1k到10k之间－－当然比flickr小多了。但是监控性能下来，目前只达到系统负载的25％左右。一台机器的数据总量在200到300GB，具体多少我忘记了。平均相应时间在10ms以下。当然，这是我server内部的数据，对用户的网络接口在我server的前面。仅仅反应的是berkeleydb所能处理的吞吐量而已。

话说回来，squid所作的cache基本上都依赖于berkeleydb来做，他做的事情是根据http协议做的一些优化（理解可能有误）。如果自己需要做某些简单的cache，不如用berkeleydb更来得合适。实际上，我觉得bdb还不太合适。B＋tree做cache有些overkill，如果没有什么频繁的数据更新，用lucene效率更高。要不是现在我们的产品负载还可以，我是想把数据移入lucene的。