談談怎樣設計秒殺服務

        上週末去百度參加了一場LBS部門的招聘專場，儘管剛換了工做，但是人力資源美眉盛情邀請，而且是週末也不用請假，本着去學習的心態去試了一下。

曾經去百度面試過幾回，面試官給人的感受仍是很是nice的，儘管不會像很是多外企的面試官會閒到給你講課，但是會和你一塊兒討論面試的問題，共同的提升。

        百度招聘，差異於360等新興創業型公司，更偏重於project師的設計技能和思惟方法。百度招聘不會深刻的考察project師所用語言的特性，陷阱等問題，而更關注考察主要的數據結構算法及其在實際樣例中的應用。

一面仍是偏向考察基本數據結構的掌握的，問了一些諸如跳躍表的實現，高速排序和堆排序，併發程序的數據同步問題等，現場寫了一個單向鏈表遞歸反轉的函數。

        二面就是偏向考察思惟方法了，因爲知道我是新浪過來的，問了一個如何設計一個大V粉絲TOP10排名的服務。另一個印象比較深的問題就是如何實現秒殺的服務。

這裏主要想和你們聊聊秒殺服務的實現方法。

        秒殺服務在平常的互聯網生活中很常見，廣告心理學曾近分析過。人們對於免費、低價等字眼的抵抗力每每很低。因此秒殺是一種成本低廉又行之有效的營銷方式。

        固然，從技術上來說，秒殺對於後端服務同一時候也是一場噩夢。試想，假設前期宣傳工做作得完備。數百萬的用戶守護在各類終端旁，在同一時刻進行請求，這個流量的峯值將會多麼的可怕。

        一個公平的秒殺，會要求請求時間排名靠前的用戶會確實的可以進行興許支付等操做。併成功買到秒殺的物品。所賣出的秒殺物品比計劃不會多一個也不會少一個。

        因爲當時面試的時間比較緊，思路不是很是清晰，想了一個取巧的方案。將秒殺的過程分爲幾個階段，如點擊秒殺，填單。支付等。秒殺這一層僅僅是進行一個大概的人數篩選，比方100個物品的秒殺。接口可以設計爲贊成1000人左右提交，以後就關閉點擊秒殺的接口。在填單和支付的時再依據點擊秒殺的排名信息肯定是否支付成功。

但是這樣的實現方法的缺陷是有一部分用戶秒殺請求成功提交，支付步奏失敗了，對這部分用戶的用戶體驗不夠好。

        回去以後細緻想了想，事實上還有更好得解決方式。可以在提交秒殺請求的時候就肯定能不能成功。

這個接口需要設計爲接收所有秒殺的請求，並在存儲中記錄一條秒殺記錄，如ID，username。秒殺提交時間等。提交以後接口會有一個小的延遲，在這個延遲內，後端會有一個離線服務對秒殺的存儲數據進行一個整理排名過濾等操做。確實的選出能支付成功的用戶列表。

秒殺服務在延遲時間後會查詢存儲的購買列表，看看這個提交的ID在不在秒殺成功的列表中。從而決定是否進行興許的步奏。

        在上一家公司一直也作過秒殺的服務，這也是個遺憾吧，在這裏隨便談談個人想法。還望高手指正~