高频面试题：秒杀系统设计

背景

最近面试面得心力交瘁&＃xff0c;由于没有高并发架构的实际项目经验&＃xff0c;经常是在场景设计的面试题目上面栽跟头。上次就被问到了关于秒杀系统的设计&＃xff0c;竟无语凝噎。痛定思痛&＃xff0c;找了一套秒杀系统的视频看了一遍&＃xff0c;总算有所理解。做个笔记&＃xff0c;希望能帮到各位。

秒杀系统设计

• 库存预热

  提前把商品的库存加载到Redis中去&＃xff0c;让整个流程都在Redis里面去做&＃xff0c;然后等秒杀结束了&＃xff0c;再异步的去修改库存就好了。


• 用户下单

  为了提升下单速度&＃xff0c;我们将订单数据存入到redis缓存中&＃xff0c;如果用户支付了&＃xff0c;再将redis中的订单存到Mysql中&＃xff0c;并清空redis中的订单。如果没有库存了&＃xff0c;则将缓存中的商品数据同步到Mysql中&＃xff0c;并情况redis中该商品的缓存。


• 创建订单

  用户每次下单的时候&＃xff0c;我们可以创建一个队列进行排队&＃xff0c;然后采用异步的方式创建订单&＃xff0c;排队我们可以采用Redis的队列实现。如果符合下单资格&＃xff0c;只需要先记录用户下单数据&＃xff0c;存入redis队列&＃xff08;先不要创建订单&＃xff09;&＃xff0c;然后采用异步创建订单的方式&＃xff0c;从redis队列中&＃xff0c;读取下单信息&＃xff0c;创建订单。


• 下单状态查询

  我们需要做一个页面判断&＃xff0c;每过1s查询一次下单状态。


• 防止重复排队

  我们用一个保存排队信息的hash键值对。用户每次抢单的时候&＃xff0c;一旦排队&＃xff0c;我们设置一个自增值&＃xff0c;让该值的初始值为1&＃xff0c;只有当该值为1的时候才能进行后续下单操作。如果值>1&＃xff0c;则表明已经排队,不允许重复排队,如果重复排队&＃xff0c;则对外抛出异常&＃xff0c;并抛出异常信息100表示已经正在排队。


• 超卖问题

  判断商品数量的时候&＃xff0c;不要用传统的读取操作&＃xff0c;而是用redis的增量命令&＃xff0c;才能确保数据的精准性。


• 订单支付

  下单成功后会跳转到支付页面&＃xff0c;支付页面会根据用户名查看用户订单&＃xff0c;创建预支付信息&＃xff0c;发送请求到支付中心&＃xff0c;获取二维码。支付状态通过回调地址发送给MQ&＃xff0c;我们需要侦听这个MQ&＃xff0c;如果支付成功&＃xff0c;则修改订单状态&＃xff0c;将订单信息写入mysql&＃xff0c;清除redis中的订单信息和排队信息等。如果支付失败&＃xff0c;则删除订单&＃xff0c;回滚库存。


• 超时支付订单库存回滚

  如果一段时间未支付&＃xff0c;则需要回滚库存&＃xff0c;删除订单操作。采用rabbitMQ的延时消息队列来实现。
Rabbitmq实现延时队列一般而言有两种形式&＃xff1a;
第一种方式&＃xff1a;利用两个特性&＃xff1a; Time To Live(TTL)、Dead Letter Exchanges&＃xff08;DLX&＃xff09;[A队列过期->转发给B队列]
第二种方式&＃xff1a;利用rabbitmq中的插件x-delay-message
TTL
RabbitMQ可以针对队列设置x-expires(则队列中所有的消息都有相同的过期时间)或者针对Message设置x-message-ttl(对消息进行单独设置&＃xff0c;每条消息TTL可以不同)&＃xff0c;来控制消息的生存时间&＃xff0c;如果超时(两者同时设置以最先到期的时间为准)&＃xff0c;则消息变为dead letter(死信)
Dead Letter Exchanges&＃xff08;DLX&＃xff09;
RabbitMQ的Queue可以配置x-dead-letter-exchange和x-dead-letter-routing-key&＃xff08;可选&＃xff09;两个参数&＃xff0c;如果队列内出现了dead letter&＃xff0c;则按照这两个参数重新路由转发到指定的队列。
x-dead-letter-exchange&＃xff1a;出现dead letter之后将dead letter重新发送到指定exchange
x-dead-letter-routing-key&＃xff1a;出现dead letter之后将dead letter重新按照指定的routing-key发送


完整资料&＃xff08;视频&＃43;笔记&＃xff09;

完整视频和笔记