前天宾总很幸运抢到了小米3,而之前黄牛们放出话来,普通人是抢不到小米3.而现在很多人因为抢不到小米3,甚至愿意加千元以上从黄牛手中购买小米3.
我也想买台小米,不过我只能买台便宜的红米.之前帮朋友抢过,不过没抢到.昨天预订了一台红米,不知道明天能不能抢到.
我想,如果这个购买程序是我写的话,又会怎么写呢.所以,我就猜想一下小米的购买程序,如果是我写,我会怎么写.有几种需求的情况,根据需求的不同,程序也就当然不同了.但有点是肯定的,都是先到先得,先到的根据人数而有概率得.
想一想,这么多人抢购小米.在到达指定抢购时间的时候,有多少人点击了抢购.就会有多少人在那一瞬间向服务器发起了请求,这是一个秒杀.不作死就不会死,但这时候作死也不能死.为了不使服务器崩溃,用户正常使用,肯定还得涉及服务器方面的一些东西.如使用排队分流,合并请求等,利用到其他的一些系统,如Redis,Memcache,Gearman等,高并发死锁检测的问题.这些服务器里的一些东西,打心底觉得还不熟悉,不研究,先只管基本的普通程序部分.
一.不分预订先后,不分地区
这样的话,对于全世界所有在抢购前预订过的人都是平等的.每个人抢购时的得到的概率是相同的,在物品售空前得到的机会平等.
1.算概率.计算每个人抢购得到的概率,即预订的总人数/此次小米售货数量.预订时,分只预订小米手机(情况一)和预订小米手机及盒子其他(情况二).两种情况都包括有小米手机,为保证机会均等,在计算概率时,直接此次小米售货数量=此次出售小米手机数量.如此次出售小米手机数量为10W台,20W人预订购买,则每次抢购的获得的概率为10W/20W=50%;
2.触发概率.通过则进入下一步,否则返回失败;
3.查存货量,加状态.用户选择小米产品,提交.给提交后,若剩余选择物品总量-发送中产品大于0,则表明用户成功抢到了小米.然后给选择物品中的发送中状态数据+1,跳入用户确认页面;
4.用户确认.从用户选择后跳入到确认页面,应设置一个时间限定,存储到服务器端,超过一定时间,确认页面将无效.用户确认,成功抢购到;超过时间限定,返回失败页;
二.分预订先后,不分地区
与一类似,请求排队可以按预订先后排队;
概率方面:
第一种办法:划出先预订的,有多少产品就划前面先预订的人数,将他们获取概率设置为100%;
第二种办法:像先预订的用户倾斜,根据预订先后,如第一个预订的ORDER为1,第二个预订的ORDER为2,总ORDER为20W,则第一个的概率为1-1/20W.当然,这样倾斜的幅度有点大,可以通过其他算法,减小倾斜的幅度;
三.不预订先后,分地区
和情况一类似,不过在计算概率和产品存货方面,就分AREA算了
四.分预订先后,分地区
二三综合了