【秒杀系统】秒杀系统之MQ的运用

前言

在春运车票大抢购、618大促、双十一等等场景，消息中间件的运用是特别广泛的

案例说明

现在的招聘，你有一个电商项目的开发经验，是十分吃香的，因为电商存在多线程、高并发、MQ、微服、消息中间件等等技术栈，所以，我们举例的话就拿秒杀系统来说

秒杀系统场景

比如说：双十一购物狂欢节，活动从双十一零点准时开始，而且抢购人数是有限的，这里我们规定只有前100名用户能享受优惠或者购买商品，那在零点前一秒的时候，同一个系统估计会有上亿个用户同时请求，那这里就出现两个问题了：

1、零点前，用户会不断的刷新页面，保证自己能够正常抢购，那此时系统应该怎么应对这种级别的并发读请求呢？

2、零点后，用户会大范围创建订单，扣除库存，操作数据库的操作，系统又应该怎么应对并发写请求呢？

这两种情况，在下面具体区分讲解

高并发读请求的处理方案

• 使用缓存技术将请求挡在请求数据库的前面

比如电商的推荐商品，这个可能会一天一个样，可以把推荐出来的结果放在缓存里面，避免了直接请求数据库的操作，效率也会大大提升

• 有些数据可以静态化的尽量就静态化

比如电商的分类，商品的分类无非就是那些，完全可以在前端写死，只是对应的分类数据要提前对应好即可

• 限流机制

限制同一个用户、ip或者同一个设备的重复请求，比如一分钟内只允许同一个人或者同一个号访问三次，多的就直接忽略

高并发写请求的处理方案

写请求，也就是创建订单、修改商品库存数据，这些操作是直接操作数据库的，如果在一秒内，上万的请求进来，数据库估计会炸，我们唯一的做法就是分洪，让这些写请求按照顺序执行，不要一次性把压力全部给到数据库，那这个时候就需要使用到消息队列 

使用消息队列的主要应对的问题

• 流量削峰：控制写操作的并发峰值，比如下单，一分钟只允许100个用户下单，其他人等下一分钟
• 异步处理：通过异步处理简化秒杀请求中的业务逻辑，比如创建订单要有日志留痕数据库，这个留痕可以异步处理掉
• 解耦：实现秒杀系统模块之间的依赖程度，更容易管理

具体怎么实现，下面讲解

1、将请求全部用消息队列来接收：用户请求接口之后，系统返回一个类似“请求正在处理”相关友好提示，让队列中的请求逐一处理完之后，把具体状态告诉用户即可

2、削峰填谷：举个例子-商品有1000个，每一次购买需要花费500ms，那1000个商品全部售罄就需要500s的时间，那此时我们有10个队列来处理，那我们只需要50s就能处理完1000个商品的购买请求，50s对于用户应该是可以接受的，一个队列处理100个请求，每次都有100个请求操作数据库，对于数据库来说肯定是没有压力的

3、异步处理：异步处理次要逻辑，比如下单，会有给用户增加积分，那主要逻辑是订单的创建和库存的扣减，次要逻辑就是发积分，那异步专门处理发积分的逻辑即可

4、解耦：比如提供一个接口专门给数据分析团队，模块相对独立