小凡陋站

从KKdata监测的京东历史价格看情人节促销

kuiGG — Tue, 07 Feb 2012 22:15:03 +0800

还有一个星期，就要到情人节了，于是各大电商网站，包括京东、天猫、淘宝等等，不管是自营还是平台，都会搞一些促销，从零食到红酒，从衣服到避孕套，跟情人节有关无关的商品，应有尽有。

京东3.7折的葡萄酒

例如京东这款“西班牙原装进口DOC里奥哈梅叠沃红葡萄酒储存酒”，虽然价格高达1300多元，但仍打出了“全场3.7折！情人节给力促销！！！”的红字招徕顾客——这里的“全场”，不是说京东全站，而是这个入驻了京东平台的这个专卖葡萄酒的商家——“沪马酒庄”。

这款葡萄酒在京东的链接是 http://www.360buy.com/product/1001275896.html ，我们可以在“360buy”的后面加上“.kkdata”，变成 http://www.360buy.kkdata.com/product/1001275896.html 就可以访问到KKdata监测的京东历史价格数据，可以看到这样的一个价格曲线：

京东葡萄酒价格曲线 from KKdata

从这条跌宕起伏的价格曲线，我们不难看出，在这次情人节“促销”之前的两个小时，这酒的价格突然从1378.10元一下子涨到3828元，涨幅达175% ！两个小时后（如果有人在这两个小时内刚好买了，那就只能哭着把这酒给喝了吧），又降回原来的1378.10元，于是就有了本次情人节3.7折的出血大促销。

另外，我们还能从这条曲线看到，中间有一个急涨急跌的“M”字型，不用说，你一定能猜到那对应的是春节大促销：实际上是从1400多涨到1900多，等着春节捞一笔，却还要告诉你，是“春节五折大促销”。

再看一下这个商家提供的其它商品，比如这款比较便宜的、80多元的葡萄酒，也是打出了3.7折情人节促销的字样：

京东葡萄酒情人节促销

再看一下KKdata提供的历史价格曲线：

京东葡萄酒价格曲线 from KKdata

明显可以看到，这是一条完全一致的曲线，虽然数值不同，涨跌比例完全相同，时间节点也完全一致。

由此可以推测：

一、京东给入驻的商家提供了整体按比例调节价格的功能；

二、要打出“XX折促销”的红字，必须有实际的降价行为；

三、京东并不在意你是否先涨后降实际持平甚至实际上涨，只要确实调了一次价格，都会把红字打上。

我们再看看其它促销商品，例如这个卖水壶的商家，号称的是“因为爱情，全场5折”（话说水壶和爱情有什么联系么）。

京东情人节水壶促销

同样按照上述的方法看看KKdata的曲线：

京东水壶价格曲线 from KKdata

同样是一条跌宕起伏的曲线，让我们默默祝福那些在曲线高点下单的同学。

不过还好，这个水壶确实降价了：经过几天依依不舍、纠结万分的挣扎，把价格从原来的50元降到了现在的34元，虽然没有5折，但人家好歹是降了16块钱啊！

不光是情人节促销，其它各种借着“节日”为名的“促销”活动（比如说圣诞风暴春节促销等等），大抵如此，先大涨，然后搞个大降。

这是京东特有的么？当然不是，淘宝光棍节的时候这种风格发扬得更加厉害。甚至可以说，因为举例的这些商品，都是入驻京东平台的商家提供的，并非京东自营，因此这不是京东的官方行为。

其实，这也不是电商特有的，在外面各大商场，几乎所有的促销都是这个套路。

所以我们作为消费者，应该是理性消费，买确实需要的、确实值得买的商品，而不是被形形色色花花绿绿的促销海报迷住双眼。

本次分析由KKdata电商数据研究中心京东站发布，查看更多京东数据，了解更多京东价格背后的秘密，请访问 http://jd.kkdata.com/ 。

KKdata 关于 2012 年 1 月份京东商品价格情况监测报告

kuiGG — Mon, 06 Feb 2012 11:54:40 +0800

本报告基于 KKdata 对京东商城非图书音像类商品价格实时监测所得数据(时间段: 2011 年 12 月 27 日至 2012自年 2 月 4 日,共计 40 天)分析得出。

一、京东商品概况

目前京东商城商品总数为171万多件，其中图书音像类商品占半数以上，因为这两类商品数目巨大且价格波动不具备代表性，所以本报告暂不把其价格纳入分析范围。

普通自营类商品指的是京东商城直营部分商品，品牌合作指的本报告基于 KKdata 对京东商城非图书音像类商品价格实时监测所得数据(时间段: 2011 年 12 月 27 日至 2012自年 2 月 4 日,共计 40 天)分析得出。

是入驻京东POP开放平台的商家提供的商品。两者比例大致在1：7左右，品牌合作商品远多于京东自营商品，可见京东已经从一个自营的独立B2C商城转变成为一个兼具综合性和开放性的电商平台。也因为品牌入驻的商品数量占明显优势，京东整体价格指数波动受其影响很大，在服饰鞋帽等类目尤为明显，下文将会详细分析。

从价格分布图可以看出，自营和品牌类商品价格主要分布在30-100元、100-500元两档，而图书音像类主要分布在30元以下。

详细的价格分布qing k可以参阅京东全部商品价格区间分布图：http://jd.kkdata.com/pricelist

二、整体价格情况

此图显示的是京东全部非图书音像类商品价格情况，以2011年12月27日为基点，在此后40天内总体处于涨价趋势，40天指数均值为+2.1852%，并于两个月初点达到峰值（1月1日：+5.1662%；2月1日：+6.1848%），从直方图也可看出，两个月末点的涨价活动最为频繁。

以下把自营商品和品牌合作商品分开看看：

自营商品40天平均指数为+1.7015%，也于月末涨价最为频繁，但指数峰值并不明显（1月1日：+2.0064%；2月1日：+2.8618%）。

从此图可以明显看出，品牌合作类商品的价格指数曲线与全部商品指数曲线基本吻合，这是由于其相对于自营商品在数量上的绝对优势所导致。

另外再看一下品牌合作的服饰鞋帽类目的情况：

同样因为数量优势，这个曲线跟全部品牌商品乃至全站商品的曲线都非常吻合。

品牌合作商品40天平均指数为+2.2631%，月初数峰值明显（1月1日：+5.6536 %；2月1日：+6.6958 %）。

另外从以上四个直方图都可以看出，从1月21日到1月28日，春节放假期间，涨价和降价的行为都大幅减少，指数曲线也趋于平缓。

二、一些自营类目的价格情况

四、一些有意思的图表

更多图表请看http://jd.kkdata.com

这个伊莱克斯吸尘器是陶然用来说明京东涨价26%的商品，其实我认为这只是一种策略性涨价，为了促销而先涨价后降价，京东有大量的这一类商品，并不能说明整体涨价幅度。

京东也有大量商品涨价降价极为频繁，刚好在降价的时候买到纯属运气：

一个避孕套的价格变动，可是大有玄机的：

京东还有很多图书，最近每天降价一毛钱：

京东涨价最凶猛的商品类目是什么？是卫生巾：

（1月5日到1月6日价格指数有波动，但并无商品涨价或降价，是因为这期间有商品上架或下架所致，并不是数据错误）

五、价格指数的算法说明

首先说明一下商品单日平均价格的概念。一个商品在一天之内，有可能会在不同的时间段有不同的价格，把每个价格与这个价格所持续的时间相乘，求和，再除以商品在本日内处于在架上的状态的总时间，即得商品单日平均价格。

然后算出单个商品每天的价格指数：

在所要分析的时间段内，取商品第一天的价格为基准，例如：如果历史上就已经上架的商品则取第一天（12月27日）的价格为基准，如果在分析时间段内上架的商品，则取第一次上架时的价格为基准。此后该商品所有价格的变化都以这个基准取比例，即得单品价格指数。

把一天内所有单品价格指数求平均，即得总体价格指数。

本来每个商品权重是不一样的，最好的权重值就是商品销量，不过京东商品的销量在网站上没有公开，无法获得，所以没有把这个权重计算进去。将来kkdata会尽量设计一个比较科学的权重值。

六、版权说明

如需进一步获得更多详细数据，请通过邮箱联系KKdata（a@kkdata.com）。

威瑞信向ICANN申请执法权以响应域名被恶意使用

kuiGG — Wed, 12 Oct 2011 16:54:13 +0800

外媒报道，全球互联网专业域名服务提供商威瑞信（Verisign，纳斯达克代码： VRSN）于10月10日向ICANN（互联网名称与数字地址分配机构）提交申请，请求批准其新的反滥用域名政策。这个新政策如果获得ICANN批准，威瑞信将被允许对其提供服务的后缀（.com， .net和.name等）域名进行扫描，以检测恶意网站或钓鱼网站，扫描以季度的形式实行。如果该域名被认定为恶意使用，威瑞信将会对域名进行移除或锁定。

这个政策旨在赋权威瑞信采取迅速行动，终止其所掌管的域名之恶意使用。

至于域名持有人关注的正常使用域名被不当移除的问题，威瑞信表示将提供申诉渠道以恢复原有域名。

为SAE写的一个mysql操作类

kuiGG — Wed, 12 Oct 2011 15:24:13 +0800

最近在新浪的云平台（SAE，http://sae.sina.com.cn）中做应用，本来使用SAE提供的mysql操作类SaeMysql（http://apidoc.sinaapp.com/sae/SaeMysql.html），但是有些不方便：

1、SaeMysql没有提供完整的增删查改方法，插入数据、删除数据、更新数据都只能自己写完整的sql然后在使用runSql 方法执行；

2、要先初始化$mysql = new SaeMysql();，以后要在其它函数内进行mysql操作的话，都不能忘了把$mysql 列入全局变量；

3、我不赞成在具体的业务代码中直接使用SAE提供的类，以后要是把应用迁移出SAE，会比较麻烦。

所以我自己把SaeMysql重新封装了一下，自己写了个mysql操作类。

代码如下：

//by kuiGG www.kuigg.com
class kuigg_Db {

function tbname($tb) {
return “kuigg_{$tb}”;
}

function getdata ($arr , $separator = ‘,’) {
$str = $s = ”;
foreach ($arr as $k => $v) {
$str .= $s.”`{$k}`=’{$v}’”;
$s = $separator;
}
return $str;
}

function fetchitem ($tb , $field , $terms = ”){
$o = & self::in();
$tb= self::tbname($tb);
$data = array();
$query = “select {$field} from `{$tb}` {$terms}”;
return $o->getVar($query);
}

function insert_id() {
$o = & self::in();
return $o->lastId();
}

function &in() {
static $object;
if(empty($object)) {
$object = new SaeMysql();
}
return $object;
}

}

下载地址：http://www.kuigg.com/attachments/2011/10/kuigg_Db.rar

这个类不需要实例化，调用里面的方法的时候只需要以kuigg_Db::function的形式就可以。

下面解释一下这里面的几个方法：

tbname：这是处理表名的方法，给表明增加前缀用。

重点是提供了完整增删查改方法：

增：insert($tb, $arr, $getinsertid = false, $replace = false)

需要提供的几个参数分别是$tb：需要插入的表名；$arr：把插入的数据按照key=字段名，value=值的形式构造的数组；$getinsertid：是否获取新插入的id，默认为false不获取，如果设为true就会返回id值；$replace：是否以替代方式插入，默认为false，一般也用不到。

示例：

$arr = array(‘user’ => ‘kuigg’ , ‘email’ => ‘i@kuigg.com’ , ‘website’ => ‘http://www.kuigg.com’);

$uid = kuigg_Db::insert(‘user’, $arr, true);

删：delete($tb, $terms = NULL,$getarows = false, $limit = 0)

需要提供的几个参数分别是$tb：需要删除数据的表名；$terms：删除的条件；$getarows：是否获取被删除的行数，默认为false不获取，如果设为true就会此次操作删除的行数；$limit：删除的行数，默认0即删除所有符合条件的行。

示例：

$rownum = kuigg_Db::delete(‘user’, “`uid` = ’1′”, true);

查：提供了4个方法：

fetchdata ($tb , $fields = ‘*’ , $terms = ”)

fetchrow ($tb , $fields = ‘*’ , $terms = ”)

fetchitem ($tb , $field , $terms = ”)

count ($tb , $fields = ‘*’ , $terms = ”)

分别可以取得多维数组、单维数组、单项值、统计数目。

改：update($tb, $arr, $terms = NULL , $getarows = false , $low_priority = false)

需要提供的几个参数分别是$tb：需要更新数据的表名；$terms：需要更新的条件；$getarows：是否获取更新的行数，默认为false不获取，如果设为true就会此次操作更新的行数。

$arr = array(‘user’ => ‘kuigg’ , ‘email’ => ‘i@kuigg.com’ , ‘website’ => ‘http://www.kuigg.com’);

$rownum = kuigg_Db::update(‘user’, $arr, “where uid = ’1′ “, true);

用了这个类，将来如果把应用迁出，只需要把这个类修改一下就可以了。

淘宝群雄起义带头大哥何在

kuiGG — Wed, 12 Oct 2011 10:54:27 +0800

昨天晚上，韩都衣舍赵总发出一条微博：刚刚接到一条信息：赵总，十万火急通报。有几个群要打一些淘宝大店的主意，其中包括你们家。就是因为这次商城改革，据目前知道的规模有几千人，他们决定整死一批商城的大店。现在赶紧赶回办公室，发现他们的行动果然已经开始了，立即召集有关负责人开会，商量对策。

配图中显示，起义军攻击商城卖家的手段是：1000人同时拍下一个店的同一件商品，拍完他就要发货，要是不发就全部申请赔偿，按照淘宝规则，72小时不发货是可以获得赔偿的，然后这个店就会被扣分扣到关门。如果全部发货，那么1000个人全部确定收货，全部给0分，马上把它的评分拉到最低值，没人再敢去买这个店的东西。这还不够，还要1000个人同时申请退款，按照淘宝商城规则，7天内是可以无理由退款的，然后该店单品的退款率马上到了100%，自然也不会有人敢买。

此微博一发，在江湖上引发了热议，对韩都衣舍等大卖家幸灾乐祸者有之，对淘宝商城新政慷慨激昂者有之，唯恐天下不乱者有之，仿佛一场腥风血雨即将到来，其真实全不亚于当年的反百度。

据悉，这场暴乱的导火索就是淘宝在双十节宣布提高对商城卖家的收费，将原有的每年6000元的技术服务年费提高至3万元和6万元两个档次，最高提升幅度达到原来的10倍。此外还将升级商家管理体系，建立“商家违约责任保证金”制度，商家进驻淘宝商城需要缴纳最低1万，最高15万的保证金。商家一旦有达到一定程度的违约行为，将扣除至少1万元的保证金。

其根本在于马云和阿里的理念转变，希望打造一个小而全的C2C、大而精的B2C，而如今的淘宝商城进驻的卖家过多，质量良莠不齐，显然达不到其预期的“精”,所以他们希望通过提高资金等各方面门槛的方式，驱逐商城中实力较弱的中小卖家。此举被称为过河拆桥，兔死狗烹，淘宝商城在过去一年内迅速发展，离不开商城中大量中小卖家的支持，有的甚至是割肉支持，跳楼支持，卖妻支持，而如今淘宝却要打小扶大，劫贫济富，不得不令他们委屈、愤怒。

起义爆发之后，韩都衣舍等大卖家纷纷将商城中的货品迅速下架，以消极方式应对攻击。而阿里巴巴向来强势，加之此次事关战略转型，回应“不会因为恐吓而放弃原则”，而且宣布“已经报警”。不过我不知道，报警能干啥，难道对这几千人跨省抓捕么，抓捕了又以什么罪名惩处他们？

据悉，此次起义组织起来的人数多达6000-7000，且分工明确，组织严密，整个群体分为30多个执行小组，每个小组有一两个人作为总监，负责策划和主持活动，分别针对不同的淘宝商城大店发起攻击。

照理说，组织这么几千个人起来同时起义，绝非易事，纵然中小卖家有愤怒有委屈，但是能一下子凝聚成这么大的力量吗？

所以我隐隐觉得，此次起义背后一定有一个“带头大哥”。

在新浪微博搜索“淘宝”，除了淘宝之外，出现得最多的是什么，是“品聚”、“葛斌斌”啊亲！再去品聚官方和葛斌斌同学的微博看看，出现得最多是什么，是“淘宝”啊亲！

而且葛斌斌同学在11号下午就宣布要卖坦克！坦克啊！不是模型！坦克是干啥用的，是起义用的，是打仗用的。

葛斌斌此人向来善于吹牛，当初出来搞电商，就搞了个概念“快乐电商”，还宣布“一年与淘宝平分天下，两年打趴淘宝，三年上市”，然后起个不知所云的奇怪名字“蛛族途”，放一幅明显针对淘宝的宣传图，被大家嘲笑起的名字垃圾，用的域名垃圾以后，用iPad作为奖励，到处征名，最后定为“品聚”。

最近品聚准备上线，上来上去现在就是一个跟团购差不多的玩意，最近又炒作卖坦克，很难说这次淘宝起义不是葛同学在作为“带头大哥”策划。

天翼QQ号码试用记录：手机号只是个马甲

kuiGG — Mon, 10 Oct 2011 17:12:11 +0800

今天看到微博上说天翼QQ目前已经可以注册，电信手机号码均可注册为QQ号，于是试用了一下。

申请的地址是 http://chinatelecom.zc.qq.com/index.html ，打开后界面很简单，任何人都会操作。

输入手机号码之后，收取验证码，验证通过以后就进入详细资料表单。

填写完这些简单的资料，确定之后就注册成功了！

注册成功的提示页面上面提供了一个“立即登录QQ” 的按钮，点击之后会直接调出电脑的QQ客户端，但是登录失败，我想到可能是QQ版本的问题，于是我按照下面的提示，下载了最新版的QQ，登录依然失败，提示该号码不存在。

然后我使用了手机QQ、QQ for pad登录，无一成功。最后试了webQQ，能够成功登录，并且能够和别的QQ加为好友，互相通话，正常使用。

我想可能是webQQ使用的数据库和客户端不同步，而客户端的数据库尚未升级的原因。但是我觉得，11位的号码和10位、9位的号码应该没太大区别啊，不至于说要做很大的改动才能兼容。

在webQQ里面玩了一阵，我发现了一个不同寻常的地方：外表上看我的手机号13391527663已经注册为QQ号，能正常使用，但是这也许并不是实际的QQ号码，很可能只是一个“马甲”。

我把鼠标悬停在QQ名字上面，显示的QQ号码是一个十位数：2791527663：

为了验证这个号码，我登录了QQ邮箱。在QQ邮箱的帐户管理里面，显示的QQ邮箱是2791527663@qq.com，而13391527663@qq.com 是作为手机号邮箱存在的。这就证明，我申请下来的这个QQ，实际的号码是2791527663，只不过绑定了一个手机号作为别名，也就是马甲。

甚至我还可以注销掉这个手机号邮箱，这样QQ邮箱就成了唯一的2791527663@qq.com：

然后，我还可以绑定其它手机号到这个QQ邮箱上面：

我又突发奇想，是不是在邮箱里面绑定了其它手机号，那么我这个QQ号的“马甲”是不是也变成了其它手机号呢？也就是说，是不是我原来注册的手机号就登录不了了，而应该用新绑定的这个手机号登录呢？验证了一下，并不是这样的。原来的手机号仍然能够登录这个QQ，而新的手机号是无法登录的。这样的话，就会出现这样的情况：QQ号码是一个手机号，而这个号码的QQ邮箱不存在，QQ邮箱对应的是另一个QQ号（真正的QQ号）和另一个手机号（新绑定的手机号），这种三号并存的现象不甚和谐，不知道QQ后面会如何解决。

由此看来，QQ并不是简单的把手机号作为一个QQ号码存在数据库里面，而是把手机号作为另一个新QQ号的马甲来处理，而且真正的QQ号还不能被发现被使用，这背后是做了比较复杂的工作的，也就解释了客户端暂时无法登录天翼QQ的问题。

还有一个问题就是，如果我不再使用这个手机号了，新的手机号主人希望申请这个QQ号，该怎么处理呢？

我注意到天翼QQ注册界面上有一个“找回天翼QQ号码”的功能选项，点开以后同样是一个输入手机号码，收到验证码的表单，那是不是这样操作之后，验证了新的手机号主人，新的手机号主人就可以直接获得这个QQ号呢？我亲自操作了一下，发现输入验证码之后实际上是进入到QQ密保系统去找回密码，那何必要发一次手机验证码呢，完全多此一举。

后来找到了QQ的官方说明：如果中国电信手机号码不再使用（以中国电信销户时间为准），您的天翼QQ号码将被我们收回。我们会在获取中国电信的销户名单后，先进行登录tips提醒，提醒期间，您依然能通过手机号码登录，但天翼QQ号码将在60天内回收，届时将无法通过该号码登录QQ相关服务。

但是有一个问题，手机号易主不一定要经过电信销号这个环节，可能是直接转让，或者过户，出售等等。就算经过销号这个环节，那么以手机号被销户为理由注销我的QQ号码，并不是很合理。这样的话，应该很少有人敢把这个号码当作日常主要的QQ号使用，毕竟手机换号的频率也挺高的。

我家媳妇做的龙猫和愤怒的小鸟

kuiGG — Wed, 14 Sep 2011 00:07:02 +0800

这个博客都已经荒废一年多了，很久没有发文章了，最近这个博客可能要活动起来了。先随便发一篇热热身。

这是我家媳妇做的龙猫和愤怒的小鸟，用软陶捏了然后烤硬的，我一直很羡慕心灵手巧的孩子啊。。

龙猫

下载权限控制机制

kuiGG — Fri, 06 Aug 2010 16:16:29 +0800

要对下载的权限进行精确的控制（防止盗链，防止迅雷吸血，下载扣除积分等虚拟货币），以前接触的方法有几种：
1、通过rewrite不断地更改下载文件的url，并插入很多无意义的字符；
2、验证下载链接的来路，或者cookie；
3、通过服务器端程序（例如一个php文件），open文件，读取内容然后返回给客户端。

第一种方法很笨，而且吃力不讨好；
第二种方法很容易破解，因为referer和cookie都是客户端发出的，能够方便地伪造，而且迅雷对此已经是轻车熟路；
第三种方法是可行的有效的，所有的文件都经过一个程序读取并发送，在读取之前可以有效的验证权限，但是下载过程中始终要占用一个cgi线程，而且一般cgi语言的IO性能都不好，速度很慢，占用了服务器的大量资源，导致总体效率极其低下，难以大规模运用。

为此我研究了一下csdn下载频道的实现机制。
csdn下载频道能够有效的验证权限，扣除积分，而且不排斥迅雷等下载客户端，同一个用户下载同一个文件也不会重复扣除积分，而且下载时始终没有暴露文件的真实地址，同一个下载URL到了别的地方也完全不可用，可以说是实现得比较理想的。

我选择了一个文件进行测试，下载的url是： http://dldx.csdn.net/fd.php?i=573624740728082&s=4fc2353ca769a0ebd9237b6f98791679

这个url向文件存储服务器上的fd.php文件发送了两个经过加密的参数，里面应该包含有用户登录信息（用户ID和sid）和目标文件的ID号。
用迅雷下载这个文件，截获返回的头信息：
Host: dldx.csdn.net
Pragma: no-cache
Range: bytes=0-
Referer: http://d.download.csdn.net/down/2474072/waf9898
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; )
HTTP/1.1 206 Partial Content
Server: nginx/0.7.65
Date: Tue, 22 Jun 2010 07:08:21 GMT
Content-Type: “application/octet-stream; charset=utf-8″
Content-Length: 667747
Last-Modified: Mon, 21 Jun 2010 23:45:02 GMT
Connection: keep-alive
Content-Disposition: attachment; filename=”DNF%E6%82%A0%E6%82%A05%5B1%5D.7.rar”
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Content-Range: bytes 0-667746/667747

这里面始终没有暴露目标文件的真实路径，不是一般下载系统所使用的header重定向的方式。而且有一个重命名的信号。服务器使用的程序是nginx/0.7.65。
根据这些信息，在google搜索到这篇文章：http://kovyrin.net/2006/11/01/nginx-x-accel-redirect-php-rails/
显然，csdn就是使用了文中所说的nginx X-Accel-Redirect。

解释一下整个过程：

步骤1，客户端请求http://dldx.csdn.net/fd.php ，并传递相关信息；

步骤2，fd.php根据所传递的信息判断出访问者的身份和所请求的资源，然后应该验证了客户端的IP，进一步判断其权限。如果这个客户端有权下载此文件，则在HTTP header加入X-Accel-Redirect: （文件的真实路径），并加上head Content-Type和Content-Disposition:；

步骤3，nginx得到fd.php的回应后发现带有X-Accel-Redirect的header，那么根据这个头记录的路径信息打开目标文件；

步骤4，nginx把打开文件的内容返回给客户端。

这样所有的权限检查和积分扣除等操作都可以在步骤2内完成，而且fd.php返回带X-Accel-Redirect的头后，其执行已经终止，剩下的传输文件的工作由nginx 来接管，同时X-Accel-Redirect头的信息被nginx删除，不会返回给客户端，也就不会暴露（实际上可以把目标文件存储在不能经由web访问的目录），并且由于nginx在打开静态文件上使用了 sendfile()，其IO效率非常高，比php的IO要快上N++倍。

这是一种优雅，有效，高效的实现方案。

因为没有架设过nginx服务器，我希望能在apache实现这个功能，于是查找了一下有没有类似的mod，果然查找到了一个mod_xsendfile：http://tn123.ath.cx/mod_xsendfile/ ，其实现机制与nginx的X-Accel-Redirect基本相同。

下载之后在本机测试。

1、加载mod_xsendfile。将文件 mod_xsendfile.so 移动到 apache/modules 目录下，将以下内容添加到httpd.conf中
LoadModule xsendfile_module modules/mod_xsendfile.so
XSendFile On
XSendFileAllowAbove On

2、使用PHP调用X-sendfile。代码如下：
接收_GET数据并解密；
验证uid、sid、文件id；
如果通过验证：
｛
扣除积分、计数统计等操作；
header('Content-Type:(目标文件类型)');
header('Content-Disposition: attachment; filename="(希望客户下载到的文件名)"');
header('X-Sendfile:(目标文件真实路径，使用绝对路径，例如"E:/www/dl/test.rar'，此路径可以是web无法访问的目录")');
exit;
｝
如果不通过：
｛
给客户端返回一个提示性的html文件；
｝

3、构造下载url，用迅雷成功下载；破坏验证条件（比如改变客户端IP）之后，迅雷只能下载到提示错误的文件。

实际应用中可以采用以下具体方案：
1、把所有的目标文件都存储在服务器B，此服务器不需要数据库，而且通过web只能访问到某入口文件（比如http://dldx.csdn.net/fd.php），在这个文件中配合apache实现X-Sendfile；
2、网站文件（php和html），以及数据库运行在服务器A（当然数据库也可以另设服务器），此服务器负责构造类似于 http://dldx.csdn.net/fd.php?i=573624740728082&s=4fc2353ca769a0ebd9237b6f98791679 的url；
3、服务器B接到以上URL以后，分析客户端IP，然后远程连接服务器A的数据库，把uid，sid，文件id，客户端IP进行匹配分析，通过则扣除积分放行下载，否则提示错误。

此方案最终就能够实现以下目的：
1、任何方式都无法直接通过web访问到目标文件，迅雷也没有办法；
2、类似于http://dldx.csdn.net/fd.php?i=573624740728082&s=4fc2353ca769a0ebd9237b6f98791679 的URL没有通用性，只能特定的用户在特定的IP访问特定的文件，迅雷即使把这个URL存储起来，也是没有办法吸血的（只能下载到提示错误的文件）；
3、文件存储和数据库两台服务器干净的分割，便于维护；
4、速度和效果都很完美，不会产生验证差错，也不会过多占用服务器资源。

中等规模相册的上传存储机制初探

kuiGG — Mon, 02 Aug 2010 11:15:18 +0800

这里对中等的定义是：图片文件所占空间在1TB–99TB。

这个机制是研究了人人网等一些UGC网站所得出的方案。

以4台服务器为模型：相册所属的主站服务器A、主站所用的Mysql服务器M、接收并处理上传文件的服务器B、最终存储图片文件并提供http下载的服务器C。实际应用中C应为多台服务器分布式存储。

首先，上传图片的入口在A上。那么，上传表单所属的html文件应该存储在A还是B呢？第一感觉应该是在A上，然后表单的action指向B，这样就可以直接把文件数据提交到B。但是事实上，我们通常会在相册中使用ajax提交表单，如果表单在A上，而数据提交到B，就会造成跨域的问题。所以，我们把这个表单部署在B上，通过同一个根域的cookie和存储在M上的session数据来验证用户身份。

B的基本任务是：验证，去重，处理，存储。

验证：B接收到数据以后，先判断文件大小和Content-Type、扩展名等是否符合要求。

去重：去重基本被大多数人忽略，我想是因为对很多网站来说短期内可以承受，但是实际的经验是，重复图片会占到50%以上的惊人比例，一些流行的图片会被不断地上传。而且这里还关系到一个审核的问题，比如一些流行的黄图或者不和谐的政治图片会被频繁上传，如果没有去重机制，会加大审核的工作量。所以，有必要对上传的每个文件取得一个二进制的MD5值，存储到数据库里。这里存入的不是M上的数据库，而是B自带的数据库。上传来的文件，如果MD5重复，就直接返回已经存在的图片路径；如果不重复，就插入新的数据，返回新的路径；如果该图片已经被判定违规，就返回一个错误信号。

处理：生成缩略图，可能是不同分辨率的缩略图。如果有需要，还得添加水印。

存储：存储分三部分：M上的数据库有相册图片相关的信息需要存入；B上的数据库也有文件信息需要存入；最后还得把文件存到C上，才能提供http下载。第一第二步不再叙述，第三步初步决定使用ftp（直接把上传的流写入ftp，B、C通信速度应该很快），也可使用专门的分布式存储系统来实现。路径可设计为 http://域名/分布式目录/20100730（年月日）/1355（时分）/large（不同大小）_（随机码）.jpg，把这个路径分解以后存储到M即可。

不要在网上随便贴自己的照片,看这只兔子的教训

kuiGG — Thu, 24 Jun 2010 13:51:50 +0800

兔子原照