比如我要根据一个专业的产品API提供商那里拿到一些产品数据，是通过PHP的CURL方式来拿数据的，
数据的内容就是产品的简介，标题，价格等。
还有一种方式就是将拿到的数据存到本地服务器硬盘一个HTML文件，用的时候include 一下。是哪种方式好呢，因为我觉得通过对方专业的API服务器拿数据，对方是有上千台服务器提供不间断的服务的。而我的本地服务器就一台，缓存一做多了，比如一千万个产品，这样效率也会越来越慢的，还不如直接从远程的大型集群服务器来拿数据呢。大家是觉得怎么搞好一些呢？
数据的内容就是产品的简介，标题，价格等。
还有一种方式就是将拿到的数据存到本地服务器硬盘一个HTML文件，用的时候include 一下。是哪种方式好呢，因为我觉得通过对方专业的API服务器拿数据，对方是有上千台服务器提供不间断的服务的。而我的本地服务器就一台，缓存一做多了，比如一千万个产品，这样效率也会越来越慢的，还不如直接从远程的大型集群服务器来拿数据呢。大家是觉得怎么搞好一些呢？
其次，民用网络带宽速度再大也还没到达超越SATA接口和数据线的传输速度。单论速度的话，肯定是本地快。影响你效率的不是你的产品和缓存数量，而是pv和并发请求数。那么如果你的pv数量大的让你连本地i/o都承受不了了，那么我相信对于你的服务器来说做同样次数的http请求就更承受不了。你可以找个压测软件，试试服务器每秒最多能发多少个请求出去。你所谓1000万个产品建立1000万份缓存文件。只要你不把这1000万个文件都放在一个目录下，而是分为一定的层级数量，也不会很慢。以平衡树的目录结构存储这1000万份文件，也就是b tree结构。可以极大提高搜索效率。只不过这个目录级别(也就是树的高度)需要斟酌考虑下，如果没记错的话，mysql的b tree最大级数好像是64。
最近在研究那个taobao的tae框架...蛋已经痛麻了.
因为
API 取得的是动态数据
include 取得的是静态数据
数据源不同！但两个方案都是可以实用的，当要求较强的实时性是用方案一，反之用方案二
我目前是开了1000个目录，每次截取产品ID的最后三位，然后 int 一下，做为目录名称
这样就可以保证1000个目录平均的存放100万或1000万个文件。
哈哈，这位哥哥的API每天调用次数多少呀，成功率呢
我的成功率最近一直低于98%
产品次数也就30多万次吧
没做淘宝客，只是把开放平台的各种API都给研究了一轮，当然除了那些遥不可及的增值部分.