情景:如何设计尖峰系统
最编程
2024-04-14 07:21:44
...
来自hollis八股文
设计一个秒杀系统需要考虑以下问题
秒杀系统存在的问题
1. 高并发流量
2. 热点数据
3. 库存正常扣减
4. 重复下单
5. 对普通交易的影响
6. 业务手段
7. 黄牛
高并发流量
将请求链路变短,把一些流量挡在外面
1. 使用CDN服务存储静态资源,降低服务器开销
2. 使用nginx做黑白名单,过滤掉行为不正常的用户
3. 使用本地缓存,redis 替代数据库进行商品库存扣减
热点数据
一般来说秒杀系统会预测到哪个商品是热点数据
1. 将热点数据放入redis中进行预热
2. 解决热key问题
加入本地缓存,减少缓存请求链路
做redis集群架构,备份热key
将热key拆分,比如 淄博001 淄博002,再根据id对key进行映射
库存的正常扣减
为了高并发,将库存放入redis做扣减
1. 利用redis做缓存,抗住并发流量
2. redis发送mq信息给mq client,进行数据库库存扣除
mq发送会出现,消息丢失问题(少买)
下订单的时候,进行账单表的统计
定时去进行对账
重复下单
1. 解决接口幂等性的问题
一锁二判三更新
2.
- 提交表单前,获取token令牌,并将其存储在redis中
- 提交表单时,一并将token提交并检验和删除,这一步属于原子操作,我们使用lua脚本
3. 订单重复性判断
黄牛
1. 令牌桶或者漏桶
2. 识别黄牛id、ip 加入nginx黑名单
业务相关
预售就开始进行筛选
推荐阅读
-
电子商务后台 | 如何设计电子商务订单系统?
-
springboot 摄影器材租赁系统设计与实现 341w5 [独家源码] 如何选择高质量的计算机毕业设计
-
软件测试/测试开发|如何使用情景方法设计测试用例?
-
什么是可用性测试?有效性(Effectiveness)-- 用户完成特定任务和实现特定目标的正确性和完整性程度;效率(Efficiency)-- 用户完成任务的正确性和完整性程度与所用资源(如时间)之比;满意度(Satisfaction)-- 用户在使用产品时的主观满意度和接受程度。 2.如何获得可用性? 可以参考以下原则:Gould、Boies 和 Lewis(1991 年)为以用户为中心的设计定义了 4 个重要原则: 早期以用户为中心:设计者应在设计过程的早期就努力了解用户的需求。 综合设计:设计的所有方面都应同步发展,而不是按顺序进行。使产品的内部设计始终与用户界面的需求保持一致。 早期和持续测试:当今唯一可行的软件测试方法是经验主义方法,即如果实际用户认为设计可行,该设计就是可行的。通过在整个开发过程中引入可用性测试,用户就有机会在产品推出之前对设计提出反馈意见。 迭代设计:大问题往往掩盖了小问题的存在。设计人员和开发人员应在整个测试过程中对设计进行迭代。 3...什么是可用性测试? 可用性测试是根据可用性标准对图形用户界面进行的系统评估。 可用性测试是衡量用户与系统(网站、软件应用程序、移动技术或任何用户操作设备)交互时的体验质量。4.如何进行可用性测试? l 实验室实验
-
建筑设计可用性测试:如何进行系统可用性测试
-
如何用 Java 实现分布式系统的架构设计
-
情景:如何设计尖峰系统
-
大型企业的优惠券系统是如何设计的?
-
如何设计缓存系统:缓存渗透、缓存击落、缓存雪崩解决方案分析
-
趣谈留言队列,搞清楚留言队列到底是什么!-说到消息队列,洪觉大概能猜到人们听到消息队列的反应,大致可以分为以下几类人。 第一类人,懵懵懂懂,刚上大学接触编程,还没用过消息队列,甚至还以为消息队列就是代码里面要新建一个List之类的;第二类人,听过消息队列,了解消息队列,但具体是什么还不是太明白,只知道一说到消息队列,脑海里马上出现了三组词,削峰、异步、解耦;第三类人,用过消息队列,对它有一定了解,但不知道为什么要这样设计,消息队列有什么样的前世今生,是如何演化到现在的模式的?**第四类人,已经对消息队列有了足够的了解,可以阅读本帖作为复习和温习。**你属于哪一类?无论你对消息队列了解多少,读完这篇文章后,我相信你都会有所收获。 什么是消息队列?我们为什么要使用消息队列?真的只是因为它看起来很勉强、很常用吗?当然不是,一项技术的出现往往是为了解决某种痛点,我们就从这个痛点出发,看看消息队列到底是为了解决什么问题而诞生的。 相信大家在工作之前,或者工作中接触单片机的次数会多一点,不管什么业务都一股脑塞进一个系统里,这种情况下接触消息队列的场景会比较少。但随着业务的增长,量上去了,单机系统就很难维护了,也扛不住并发量的增长,就需要把原来的单体应用拆分成多个服务。例如,牛奇网采用分布式架构,将原来的单体系统拆分成用户服务、题库服务、求职服务、论坛服务等,每个分布式节点都有一个集群,保证高可用性。 那虽然在这样的微服务架构下,如果某个核心业务并发量过大,系统就扛不住了。比如淘宝、淘票票、拼多多、京东等电商场景中的支付场景,你在某宝下单并支付后,调用支付服务,完成支付后,还需要更新订单的状态,这个时候就需要调用订单服务,那我们平时也下单,除了简单完成这些操作外,还会给你相应的积分;商家也会收到订单消息,并给您发送旺旺消息,确认订单无误;同时,也会给您发送消息,确认订单无误。确认订单无误;同时您还可以查看您的物流状态;还有系统为了给您推荐更适合您的商品,会根据您的订单做类似的推荐等等,我说的这些都是当我们下单后,肉眼可以感知到系统所做的动作。 **一个支付动作如果还需要调用那么多服务,等他们响应成功,最后再告诉用户你支付成功了,用户在系统中的整个体验会非常糟糕。**设想一下,假设请求服务+处理请求+响应总共需要 50ms,我们上面列出的场景:支付服务、订单服务、积分服务、商家服务、物流服务、推荐服务,总共需要 300ms。