上週末去百度參加了一場LBS部門的招聘專場，雖然剛換了工作，但是人力資源美眉盛情邀請，而且是週末也不用請假，本着去學習的心態去試了一下。以前去百度面試過幾次，面試官給人的感覺還是很nice的，雖然不會像很多外企的面試官會閒到給你講課，但是會和你一起討論面試的問題，共同的提高。
百度招聘，區別於360等新興創業型公司，更偏重於工程師的設計技能和思維方法。百度招聘不會深入的考察工程師所用語言的特性，陷阱等問題，而更關注考察基本的數據結構算法及其在實際例子中的應用。
一面還是偏向考察基本數據結構的掌握的，問了一些諸如跳躍表的實現，快速排序和堆排序，併發程序的數據同步問題等，現場寫了一個單向鏈表遞歸反轉的函數。
二面就是偏向考察思維方法了，因爲知道我是新浪過來的，問了一個怎樣設計一個大V粉絲TOP10排名的服務。另外一個印象比較深的問題就是如何實現秒殺的服務。
這裏主要想和大家聊聊秒殺服務的實現方法。
秒殺服務在日常的互聯網生活中非常常見，廣告心理學曾近分析過，人們對於免費、低價等字眼的抵抗力往往非常低，所以秒殺是一種成本低廉又行之有效的營銷方式。
當然，從技術上來講，秒殺對於後端服務同時也是一場噩夢。試想，如果前期宣傳工作做得完備，數百萬的用戶守護在各種終端旁，在同一時刻進行請求，這個流量的峯值將會多麼的可怕。
一個公平的秒殺，會要求請求時間排名靠前的用戶會確實的可以進行後續支付等操作，併成功買到秒殺的物品。所賣出的秒殺物品比計劃不會多一個也不會少一個。
因爲當時面試的時間比較緊，思路不是很清晰，想了一個取巧的方案。將秒殺的過程分爲幾個階段，如點擊秒殺，填單，支付等，秒殺這一層只是進行一個大概的人數篩選，比如100個物品的秒殺，接口可以設計爲允許1000人左右提交，之後就關閉點擊秒殺的接口。在填單和支付的時再根據點擊秒殺的排名信息確定是否支付成功。但是這種實現方法的缺陷是有一部分用戶秒殺請求成功提交，支付步奏失敗了，對這部分用戶的用戶體驗不夠好。
回去之後仔細想了想，其實還有更好得解決方案。可以在提交秒殺請求的時候就確定能不能成功。這個接口需要設計爲接收所有秒殺的請求，並在存儲中記錄一條秒殺記錄，如ID，用戶名，秒殺提交時間等。提交之後接口會有一個小的延遲，在這個延遲內，後端會有一個離線服務對秒殺的存儲數據進行一個整理排名過濾等操作，確實的選出能支付成功的用戶列表。秒殺服務在延遲時間後會查詢存儲的購買列表，看看這個提交的ID在不在秒殺成功的列表中，從而決定是否進行後續的步奏。
在上一家公司一直也做過秒殺的服務，這也是個遺憾吧，在這裏隨便談談我的想法，還望高手指正~