B2C电商项目秒杀业务工作总结

秒杀前端业务

秒杀商品通常有两种限制：库存限制、时间限制。

（1）秒杀频道首页列出秒杀商品
（4）点击立即抢购实现秒杀下单，下单时扣减库存。当库存为0或不在活动期范围内时无法秒杀。
（5）秒杀下单成功，直接跳转到支付页面（微信扫码），支付成功，跳转到成功页，填写收货地址、电话、
收件人等信息，完成订单。
（6）当用户秒杀下单5分钟内未支付，取消预订单，调用微信支付的关闭订单接口，恢复库存。

缓存数据加载思路：定义定时任务，每天凌晨会进行当天所有时间段秒杀商品预加载。并且在B端进行
限制，添加秒杀商品的话，只能添加当前日期+1的时间限制，比如说：当前日期为8月5日，则添加秒杀
商品时，开始时间必须为6日的某一个时间段，否则不能添加。

当前业务整体流程分析

1.查询所有符合条件的秒杀商品
1) 获取时间段集合并循环遍历出每一个时间段
2) 获取每一个时间段名称,用于后续redis中key的设置
3) 状态必须为审核通过 status=1
4) 商品库存个数>0
5) 秒杀商品开始时间>=当前时间段
6) 秒杀商品结束<当前时间段+2小时
7) 排除之前已经加载到Redis缓存中的商品数据
8) 执行查询获取对应的结果集
2.将秒杀商品存入缓存

前台

1）加载时间菜单
2）加载时间菜单下秒杀商品信息

加载时间菜单分析

每2个小时就会切换一次抢购活动，所以商品发布的时候，我们将时间定格在2小时内抢购，每次发布商
品的时候，商品抢购开始时间和结束时间是这2小时的边界。
每2小时会有一批商品参与抢购，所以我们可以将24小时切分为12个菜单，每个菜单都是个2小时的时
间段，当前选中的时间菜单需要根据当前时间判断，判断当前时间属于哪个秒杀时间段，然后将该时间
段作为选中的第1个时间菜单。

加载对应秒杀商品分析

进入首页时，到后台查询时间菜单信息，然后将第1个菜单的时间段作为key，在Redis中查询秒杀商品
集合，并显示到页面，页面每次点击切换不同时间段菜单的时候，都将时间段传入到后台，后台根据时
间段获取对应的秒杀商品集合。

时间菜单实现

时间菜单显示，先运算出每2小时一个抢购，就需要实现12个菜单，可以先计算出每个时间的临界值，
然后根据当前时间判断需要显示12个时间段菜单中的哪个菜单，再在该时间菜单的基础之上往后挪4个
菜单，一直显示5个时间菜单。

倒计时实现

基础数据显示
定义一个集合，用于存放五个时间段的倒计时时间差，集合中每一个角标都对应一个倒计时时间差，比
如：集合角标为0，对应第一个倒计时时间差。集合角标为1，对应第二个倒计时时间差，依次类推。
因为要有倒计时的效果，所以后续会遍历该时间集合，并让集合中的每一个时间循环递减即可

加载秒杀商品实现

当前已经完成了秒杀时间段菜单的显示，那么当用户在切换不同的时间段的时候，需要按照用户所选择
的时间去显示相对应时间段下的秒杀商品

秒杀后端

秒杀异步下单
用户在下单的时候，需要基于JWT令牌信息进行登陆人信息认证，确定当前订单是属于谁的。
针对秒杀的特殊业务场景，仅仅依靠对象缓存或者页面静态化等技术去解决服务端压力还是远远不够。
对于数据库压力还是很大，所以需要异步下单，异步是最好的解决办法，但会带来一些额外的程序上的
复杂性。

当预加载秒杀商品的时候，提前加载每一个商品的库存信息，后续减库存操作也会先预扣减缓存中的库
存再异步扣减mysql数据。
预扣减库存会基于redis原子性操作实现

秒杀下单业务层实现
业务逻辑：
获取秒杀商品数据与库存量数据，如果没有库存则抛出异常
执行redis预扣减库存,并获取扣减之后的库存值
如果扣减完的库存值<=0, 则删除redis中对应的商品信息与库存信息
基于mq异步方式完成与mysql数据同步（最终一致性）

注意：库存数据从 redis中取出，转换成String

生产者保证消息不丢失

按照现有 rabbitMQ的相关知识，生产者会发送消息到达消息服务器。但是在实际生产环境下，消息生
产者发送的消息很有可能当到达了消息服务器之后，由于消息服务器的问题导致消息丢失，如宕机。因
为消息服务器默认会将消息存储在内存中。一旦消息服务器宕机，则消息会产生丢失。因此要保证生产
者的消息不丢失，要开始持久化策略。

rabbitMQ持久化：
交换机持久化
队列持久化
消息持久化

但是如果仅仅只是开启这两部分的持久化，也很有可能造成消息丢失。因为消息服务器很有可能在持久
化的过程中出现宕机。因此需要通过数据保护机制来保证消息一定会成功进行持久化，否则将一直进行
消息发送。

RabbitMQ数据保护机制
事务机制事务机制采用类数据库的事务机制进行数据保护，当消息到达消息服务器，首先会开启一个事务，接着进
行数据磁盘持久化，只有持久化成功才会进行事务提交，向消息生产者返回成功通知，消息生产者一旦接收成
功通知则不会再发送此条消息。当出现异常，则返回失败通知.消息生产者一旦接收失败通知，则继续发送该
条消息。事务机制虽然能够保证数据安全，但是此机制采用的是同步机制，会产生系统间消息阻塞，影响整个系统
的消息吞吐量。从而导致整个系统的性能下降，因此不建议使用。
confirm机制confirm模式需要基于channel进行设置, 一旦某条消息被投递到队列之后,消息队列就会发送一个确
认信息给生产者,如果队列与消息是可持久化的, 那么确认消息会等到消息成功写入到磁盘之后发出.
confirm的性能高,主要得益于它是异步的.生产者在将第一条消息发出之后等待确认消息的同时也可以
继续发送后续的消息.当确认消息到达之后,就可以通过回调方法处理这条确认消息. 如果MQ服务宕机了,则会
返回nack消息. 生产者同样在回调方法中进行后续处理

消费者手动ACK下单实现
按照现有RabbitMQ知识，可以得知当消息消费者成功接收到消息后，会进行消费并自动通知消息服务
器将该条消息删除。此种方式的实现使用的是消费者自动应答机制。但是此种方式非常的不安全。
在生产环境下，当消息消费者接收到消息，很有可能在处理消息的过程中出现意外情况从而导致消息丢
失，因为如果使用自动应答机制是非常不安全。
我们需要确保消费者当把消息成功处理完成之后，消息服务器才会将该条消息删除。此时要实现这种效
果的话，就需要将自动应答转换为手动应答,只有在消息消费者将消息处理完，才会通知消息服务器将该
条消息删除。

更改配置文件将自动应答转换为手动应答

rabbitmq:host: 192.168.200.128listener:simple:acknowledge-mode: manual #手动

流量削峰
在秒杀这种高并发的场景下，每秒都有可能产生几万甚至十几万条消息，如果没有对消息处理量进行任
何限制的话，很有可能因为过多的消息堆积从而导致消费者宕机的情况。因此官网建议对每一个消息消
费者都设置处理消息总数（消息抓取总数）。
消息抓取总数的值，设置过大或者过小都不好，过小的话，会导致整个系统消息吞吐能力下降，造成性
能浪费。过大的话，则很有可能导致消息过多，导致整个系统OOM。因此官网建议每一个消费者将该
值设置在100-300之间。
1）更新消费者。

//设置预抓取总数
channel.basicQos(300);

防止恶意刷单解决
在生产场景下，很有可能会存在某些用户恶意刷单的情况出现。这样的操作对于系统而言，会导致业务
出错、脏数据、后端访问压力大等问题的出现。
一般要解决这个问题的话，需要前端进行控制，同时后端也需要进行控制。后端实现可以通过Redis
incrde 原子性递增来进行解决。

秒杀下单接口隐藏
当前虽然可以确保用户只有在登录的情况下才可以进行秒杀下单，但是无法方法有一些恶意的用户在登
录了之后，猜测秒杀下单的接口地址进行恶意刷单。所以需要对秒杀接口地址进行隐藏。
在用户每一次点击抢购的时候，都首先去生成一个随机数并存入redis，接着用户携带着这个随机数去访
问秒杀下单，下单接口首先会从redis中获取该随机数进行匹配，如果匹配成功，则进行后续下单操作，
如果匹配不成功，则认定为非法访问。

秒杀下单接口限流
因为秒杀的特殊业务场景，生产场景下，还有可能要对秒杀下单接口进行访问流量控制，防止过多的请
求进入到后端服务器。对于限流的实现方式，我们之前已经接触过通过nginx限流，网关限流。但是他
们都是对一个大的服务进行访问限流，如果现在只是要对某一个服务中的接口方法进行限流呢？这里推
荐使用google提供的guava工具包中的RateLimiter进行实现，其内部是基于令牌桶算法进行限流计算