谈谈怎样设计秒杀服务

        上周末去百度參加了一场LBS部门的招聘专场，尽管刚换了工做，但是人力资源美眉盛情邀请，而且是周末也不用请假，本着去学习的心态去试了一下。

曾经去百度面试过几回，面试官给人的感受仍是很是nice的，尽管不会像很是多外企的面试官会闲到给你讲课，但是会和你一块儿讨论面试的问题，共同的提升。

        百度招聘，差异于360等新兴创业型公司，更偏重于project师的设计技能和思惟方法。百度招聘不会深刻的考察project师所用语言的特性，陷阱等问题，而更关注考察主要的数据结构算法及其在实际样例中的应用。

一面仍是偏向考察基本数据结构的掌握的，问了一些诸如跳跃表的实现，高速排序和堆排序，并发程序的数据同步问题等，现场写了一个单向链表递归反转的函数。

        二面就是偏向考察思惟方法了，因为知道我是新浪过来的，问了一个如何设计一个大V粉丝TOP10排名的服务。另一个印象比較深的问题就是如何实现秒杀的服务。

这里主要想和你们聊聊秒杀服务的实现方法。

        秒杀服务在平常的互联网生活中很常见，广告心理学曾近分析过。人们对于免费、低价等字眼的抵抗力每每很低。因此秒杀是一种成本低廉又行之有效的营销方式。

        固然，从技术上来说，秒杀对于后端服务同一时候也是一场噩梦。试想，假设前期宣传工做作得完备。数百万的用户守护在各类终端旁，在同一时刻进行请求，这个流量的峰值将会多么的可怕。

        一个公平的秒杀，会要求请求时间排名靠前的用户会确实的可以进行兴许支付等操做。并成功买到秒杀的物品。所卖出的秒杀物品比计划不会多一个也不会少一个。

        因为当时面试的时间比較紧，思路不是很是清晰，想了一个取巧的方案。将秒杀的过程分为几个阶段，如点击秒杀，填单。支付等。秒杀这一层仅仅是进行一个大概的人数筛选，比方100个物品的秒杀。接口可以设计为赞成1000人左右提交，以后就关闭点击秒杀的接口。在填单和支付的时再依据点击秒杀的排名信息肯定是否支付成功。

但是这样的实现方法的缺陷是有一部分用户秒杀请求成功提交，支付步奏失败了，对这部分用户的用户体验不够好。

        回去以后细致想了想，事实上还有更好得解决方式。可以在提交秒杀请求的时候就肯定能不能成功。

这个接口需要设计为接收所有秒杀的请求，并在存储中记录一条秒杀记录，如ID，username。秒杀提交时间等。提交以后接口会有一个小的延迟，在这个延迟内，后端会有一个离线服务对秒杀的存储数据进行一个整理排名过滤等操做。确实的选出能支付成功的用户列表。

秒杀服务在延迟时间后会查询存储的购买列表，看看这个提交的ID在不在秒杀成功的列表中。从而决定是否进行兴许的步奏。

        在上一家公司一直也作过秒杀的服务，这也是个遗憾吧，在这里随便谈谈个人想法。还望高手指正~