秒杀系统-高性能、高可用、一致性(设置备用计划作为最坏情况的应对方法)
- 单独部署。分层减小流量、控制有效流量(避免黄牛账号批量下单)
- 设计预约功能-可以初略预估抢购秒杀人数,可以设置一部分直接获取静态动画-如库存为空;
- 前端使用动静分离、使用拼图、答题、CDN内容分发(提出问题 CDN内容分发) 来控制瞬时流量;
- 到达抢购的时候,流量进入网关处理、通过GateWay、nginx限流(通过用户、设备、ip地址、收货地址或者黑名单进行限流)—限制非常规请求
- 剩余大量的流量 可以通过令牌桶算法、sentinel这些进一步做流量处理
- 这里可以不用消息队列(如果使用消息队列 大量消息消费速度较慢)
- 通过网关将请求放入 进行下单操作,(瞬时高并发下单请求可以用RockerMQ进行流量削峰)
- 下单请求收到后、迅速生成订单对象 放入redis中,将不同用户的订单放入到不同的redis中,
- 用mq进行流量削峰、后端消费,入库可以从mq中消费,然后在做分布式事务,MQ异步消息发送;
- 商品数量少的话、期间需要用到reddssion分布式锁;
- 在服务器实例中写好商品数量;比如通过Apollo配置中心下发商品实例的数量、可以动态控制商品数量;
- 如果期间服务宕机、库存可以放入库存池中继续销售(超时未付款 );
主要解决2个问题:并发读、并发写
并发读:主要需要减少用户到服务器来读取数据、或者是读取更少的数据
并发写:在数据库层面独立出来一个库,做特殊处理;
秒杀的整体架构需要 系统稳、数据准、速度快
- 高可用:整个架构需要满足高可用、流量符合预期的时候需要稳定、保证秒杀活动的顺利进行
- 一致性:保证库存的一致性、不能多卖少卖;
- 高性能:系统的性能要求足够高