小米手機購買程序,若是是我,我會怎麼寫

　　前天賓總很幸運搶到了小米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算了

　　四.分預訂前後,分地區

　　　　二三綜合了