1.活动页面静态化处理
没有到活动时间页面静态化处理避免访问服务端

2.使用cdn让用户可以获取就近的所需静态页面内容

3.限制用户同一时间点击次数

4.把商品库存提前放入redis，秒杀请求直接操作redis防止操作直接落库打崩数据库

5.使用lua脚本操作redis保证操作原子性，确保不会发生超买超卖。
具体就是先查看商品id是否存在如果不存在则直接返回失败，如果存在且库存大于0则扣减库存返回成功，如果库存等于0则返回库存不足。

7.使用redis分布式锁限制并发数量
redission枷锁

8.消息队列异步处理
真实秒杀场景分秒杀、下单、支付等三个模块

并发量最大的就是秒杀，下单和支付并发量并不是很高，所以架构设计时把下单和支付从秒杀主流程中拆分出来，秒杀和下单使用mq异步通信。

8.1 防止mq消息丢失

消息发送前先使用消息发送记录表记录一下并且赋予状态为待处理，当下游服务消费完消息后调用消息回调接口更新消息发送记录表中的信息状态为已完成，启用job机制定期检查发送表中的消息状态，如果是未完成的状态且超过一段时间则重新发送，然后删掉状态为已完成的消息。

8.2 重复消费问题
消费者实现一个消息处理表，消费后把消息放入消息处理表中，每次重新拿到消息后判断是否已经在消息处理表中，如果在就丢弃不做处理，不在的话就执行后续下单操作执行完成就把消息放入消息处理表中。注意下单和写消息处理表要放在同一个事务中保证原子性操作。

8.3 垃圾消息处理
如果回调接口异常会使得消息在消息处理表中长时间停留且会不停的再往下游重复发送，所以要在消息处理表中记录消息重发次数回头停留时间，根据重发次数和停留时间做一个权衡策略限制垃圾消息重发。

8.4 延迟消费问题
如果用户长时间未支付，则需要取消订单，这里可以使用rocket mq的延迟队列，生成订单后状态为待支付，这时候向延迟队列发送消息，经过订单最大延迟时间后消费延迟消息，拿到消息查询订单状态如果订单状态为待支付则取消订单，若状态为已支付就修改订单状态为已支付。

9.如何限流
使用redis对用户或者对某个ip做限流，如果某一个用户或者ip访问次数过多，那么就启用验证码机制。