谈谈如何设计秒杀服务

上周末去百度参加了一场LBS部门的招聘专场，虽然刚换了工作，但是人力资源美眉盛情邀请，而且是周末也不用请假，本着去学习的心态去试了一下。以前去百度面试过几次，面试官给人的感觉还是很nice的，虽然不会像很多外企的面试官会闲到给你讲课，但是会和你一起讨论面试的问题，共同的提高。
        百度招聘，区别于360等新兴创业型公司，更偏重于工程师的设计技能和思维方法。百度招聘不会深入的考察工程师所用语言的特性，陷阱等问题，而更关注考察基本的数据结构算法及其在实际例子中的应用。
一面还是偏向考察基本数据结构的掌握的，问了一些诸如跳跃表的实现，快速排序和堆排序，并发程序的数据同步问题等，现场写了一个单向链表递归反转的函数。
        二面就是偏向考察思维方法了，因为知道我是新浪过来的，问了一个怎样设计一个大V粉丝TOP10排名的服务。另外一个印象比较深的问题就是如何实现秒杀的服务。
这里主要想和大家聊聊秒杀服务的实现方法。
        秒杀服务在日常的互联网生活中非常常见，广告心理学曾近分析过，人们对于免费、低价等字眼的抵抗力往往非常低，所以秒杀是一种成本低廉又行之有效的营销方式。
        当然，从技术上来讲，秒杀对于后端服务同时也是一场噩梦。试想，如果前期宣传工作做得完备，数百万的用户守护在各种终端旁，在同一时刻进行请求，这个流量的峰值将会多么的可怕。
        一个公平的秒杀，会要求请求时间排名靠前的用户会确实的可以进行后续支付等操作，并成功买到秒杀的物品。所卖出的秒杀物品比计划不会多一个也不会少一个。
        因为当时面试的时间比较紧，思路不是很清晰，想了一个取巧的方案。将秒杀的过程分为几个阶段，如点击秒杀，填单，支付等，秒杀这一层只是进行一个大概的人数筛选，比如100个物品的秒杀，接口可以设计为允许1000人左右提交，之后就关闭点击秒杀的接口。在填单和支付的时再根据点击秒杀的排名信息确定是否支付成功。但是这种实现方法的缺陷是有一部分用户秒杀请求成功提交，支付步奏失败了，对这部分用户的用户体验不够好。
        回去之后仔细想了想，其实还有更好得解决方案。可以在提交秒杀请求的时候就确定能不能成功。这个接口需要设计为接收所有秒杀的请求，并在存储中记录一条秒杀记录，如ID，用户名，秒杀提交时间等。提交之后接口会有一个小的延迟，在这个延迟内，后端会有一个离线服务对秒杀的存储数据进行一个整理排名过滤等操作，确实的选出能支付成功的用户列表。秒杀服务在延迟时间后会查询存储的购买列表，看看这个提交的ID在不在秒杀成功的列表中，从而决定是否进行后续的步奏。



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