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