小米手机购买程序,若是是我,我会怎么写

　　前天宾总很幸运抢到了小米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算了

　　四.分预订前后,分地区

　　　　二三综合了