实战分布式之电商高并发秒杀场景总览

本文是“实战高并发”系列的开篇,探讨电商秒杀业务场景,包括其特点、流程和异步处理的必要性。通过生产者-消费者模式,利用中间件如RocketMQ实现系统削峰填谷,提高吞吐量。
摘要由CSDN通过智能技术生成

前言

本文是新系列“实战高并发”的开篇作。这个系列作为“我说分布式”的子系列,将着重挑选若干典型的分布式实战场景,尽量对当下高并发领域较为热门的架构及业务场景做一次较为深入的实践与总结。

该系列既是对笔者接触过的业务的整理,也希望系列中分享的套路能够对读者朋友解决实际业务中面临的问题有所帮助。

言归正传,本文我将主要从业务场景及技术架构等方面出发,对”电商高并发秒杀”这一业务场景做一次较为全面的阐述,同时作为后续实操的开发设计依据。


何为“秒杀”及其特点

“秒杀”这一业务场景在如今已经不是什么新鲜名词,它本质上属于短时突发性高并发访问问题,业务特点如下:

  1. 定时触发,流量在瞬间突增
  2. 秒杀请求中常常只有部分能够成功
  3. 秒杀商品数量往往有限,不能超卖,但能接受少卖
  4. 不要求立即返回真实下单结果

分析一下这些秒杀场景的典型特点,我们不难看出,秒杀场景属于典型的高并发场景,对系统的冲击较大。我们来对上述特点进行逐一分析:

1.定时触发,流量在瞬间突增

这不难理解,秒杀活动往往伴随着固定的节日、活动而开展,在某一个确定时间对C端用户开放访问能力,此时往往会出现一个较为明显的请求激增。如:每年“双11”当天0点,淘宝等电商平台访问量基本上会出现明显的请求波峰,这与秒杀的定时性,息息相关。

2.秒杀请求中常常只有部分能够成功

这是肯定的,在库存有限、请求接收较多的情况下,常会存在部分请求处理成功,部分请求处理失败的情况。

如果库存是无限的,也就不存在秒杀这一说了。也正是因为库存有限,平台以此为卖点&#

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值