谈谈怎样设计秒杀服务
服务 设计 怎样 谈谈 秒杀
2023-09-27 14:25:17 时间
上周末去百度參加了一场LBS部门的招聘专场,尽管刚换了工作,可是人力资源美眉盛情邀请,并且是周末也不用请假,本着去学习的心态去试了一下。
曾经去百度面试过几次,面试官给人的感觉还是非常nice的,尽管不会像非常多外企的面试官会闲到给你讲课,可是会和你一起讨论面试的问题,共同的提高。
百度招聘,差别于360等新兴创业型公司,更偏重于project师的设计技能和思维方法。百度招聘不会深入的考察project师所用语言的特性,陷阱等问题,而更关注考察主要的数据结构算法及其在实际样例中的应用。
一面还是偏向考察基本数据结构的掌握的,问了一些诸如跳跃表的实现,高速排序和堆排序,并发程序的数据同步问题等,现场写了一个单向链表递归反转的函数。
二面就是偏向考察思维方法了,由于知道我是新浪过来的,问了一个如何设计一个大V粉丝TOP10排名的服务。另外一个印象比較深的问题就是如何实现秒杀的服务。
这里主要想和大家聊聊秒杀服务的实现方法。
秒杀服务在日常的互联网生活中很常见,广告心理学曾近分析过。人们对于免费、低价等字眼的抵抗力往往很低。所以秒杀是一种成本低廉又行之有效的营销方式。
当然,从技术上来讲,秒杀对于后端服务同一时候也是一场噩梦。试想,假设前期宣传工作做得完备。数百万的用户守护在各种终端旁,在同一时刻进行请求,这个流量的峰值将会多么的可怕。
一个公平的秒杀,会要求请求时间排名靠前的用户会确实的能够进行兴许支付等操作。并成功买到秒杀的物品。所卖出的秒杀物品比计划不会多一个也不会少一个。
由于当时面试的时间比較紧,思路不是非常清晰,想了一个取巧的方案。将秒杀的过程分为几个阶段,如点击秒杀,填单。支付等。秒杀这一层仅仅是进行一个大概的人数筛选,比方100个物品的秒杀。接口能够设计为同意1000人左右提交,之后就关闭点击秒杀的接口。在填单和支付的时再依据点击秒杀的排名信息确定是否支付成功。
可是这样的实现方法的缺陷是有一部分用户秒杀请求成功提交,支付步奏失败了,对这部分用户的用户体验不够好。
回去之后细致想了想,事实上还有更好得解决方式。能够在提交秒杀请求的时候就确定能不能成功。
这个接口须要设计为接收全部秒杀的请求,并在存储中记录一条秒杀记录,如ID,username。秒杀提交时间等。提交之后接口会有一个小的延迟,在这个延迟内,后端会有一个离线服务对秒杀的存储数据进行一个整理排名过滤等操作。确实的选出能支付成功的用户列表。
秒杀服务在延迟时间后会查询存储的购买列表,看看这个提交的ID在不在秒杀成功的列表中。从而决定是否进行兴许的步奏。
在上一家公司一直也做过秒杀的服务,这也是个遗憾吧,在这里随便谈谈我的想法。还望高手指正~
相关文章
- 短链系统设计-服务设计
- DDD领域驱动设计实战-服务和数据在微服务各层协作的最佳实践
- 微服务接口的防刷、防重、限量设计
- 原来阿里华为等大厂都是这么设计微服务接口的!
- 解决通过Nginx转发的服务请求头header中含有下划线的key,其值取不到的问题
- 设计干货,APP服务设计需要注意的五个点
- 基于Nodejs的志愿者服务系统的设计和实现
- IoT 云服务加速产业创新,推进规模商用
- DDD为什么能火起来?和微服务有啥关系?
- 基于Nodejs的智慧小区服务系统的设计和实现
- 幸亏有这本623页的微服务框架实战笔记,相关资料参考
- 物联网环境下的大吞吐量下消息服务集群设计
- SOA服务设计与实现的几个语言无关的原则速记
- 转:云计算的三种服务模式:IaaS,PaaS和SaaS
- WCF学习心得------(二)设计和实现服务协定
- 轻型的接口访问频率限制服务模型的设计与实现【转】
- alpine:openrc:初始化服务管理系统的一个问题:修改服务后,旧依赖依旧存在?!
- mangde 的服务启动
- spring sts4 如何添加tomcat 服务
- Netty系列之Netty百万级推送服务设计要点
- 微服务的4大设计原则和19个解决方案
- Kubernetes服务目录的设计
- 云计算服务需求促进边缘计算的应用与发展
- linux下的Telnet服务
- 微服务拆分需要考虑的必要因素与坚持原则
- 在Docker和Kubernetes上运行MongoDB微服务