秒杀本质上属于短时突发性高并发访问问题，业务特点如下：

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

场景1: 某电商网站红米K40发布在即，拥有预约码的用户可优先购买手机。预约方式为：注册账户即可获得预约码，预计预约用户超过1000万。 像双11秒杀、手机预约抢购等对 IO 时延敏感业务环境下，当外部请求超过系统处理能力时，如果系统没有做相应保护，可能由于历史累计的超时请求负荷过多而导致系统处理的每个请求都因超时而无效，系统对外呈现的服务能力为0，且这种情况下服务不能自动恢复。 这种情形下，引入RocketMQ，将非即时处理的业务逻辑进行异步化。例如服务接收请求、处理请求和返回请求三个不同的业务逻辑。

1.引入RocketMQ 后，当预约活动开始时，海量并发访问汹涌袭来： 2.所有客户的预约申请，页面均立即返回成功。客户便可关闭网页进行其他活动。预约码稍后推送到客户的邮箱/手机； 3.超过千万级别的注册、预约申请，先暂存在RocketMQ消息队列集群； 4.后端服务进行处理，按照数据库实际的 select、insert、update 能力处理注册、预约申请； 5.处理成功后返回结果给用户。预约结束后，用户大约在5 - 30min内，都收到了预约码。

场景2: 流量削峰也是消息队列 RocketMQ 版的常用场景，一般在秒杀或团队抢购活动 中使用广泛。 在秒杀或团队抢购活动中，由于用户请求量较大，导致流量暴增，秒杀的应用在 处理如此大量的访问流量后，下游的通知系统无法承载海量的调用量，甚至会导致系 统崩溃等问题而发生漏通知的情况。为解决这些问题，可在应用和下游通知系统之间 加入消息队列 RocketMQ 版。

秒杀处理流程如下所述：

场景3: 有一个点赞业务，不限制用户的点赞数只需进行记录(产品需求，开发提议无效)，当每个用户都进行x连击享受数量猛增的快感时如果数据库都需要进行x个点赞数据的插入，数据库毫无疑问会塞死导致崩溃。 于是想到可以尝试下MQ削峰，比如每秒来了5000消息但数据库只能承受2000，那我消费时每次只拉取消费1600就好了(可以在消费者设置拉取数量,然后批量入库)，剩下的放在Broker堆积慢慢消费就好。由于之前的消息中心也在用RocketMQ，于是确认使用RocketMQ来进行削峰。