如何实现一个秒杀系统

设计秒杀系统需要注意以下几点

1. 数据要尽量少

   所谓“数据要尽量少”，首先是指用户请求的数据能少就少。请求的数据包括上传给系统的数据和系统返回给用户的数据

2. 路径要尽量短

   所谓“路径”，就是用户发出请求到返回数据这个过程中，需求经过的中间的节点数。比如秒杀商品详情系统需要调用库存系统。解决多节点调用就是把RPC转换成服务内部调用。秒杀的缓存信息可以用本地缓存，如果用Redis做缓存组件的话会增加一次Socket连接。用本地缓存的话即减少了一次连接也符合路径要尽量短。使用了本地缓存动态数据需要更新就需要监听MQ来更新本地缓存的内容。

3. 依赖要尽量少

   减少弱依赖，比如不显示优惠券相关非必要信息。最近各地政府都在号召：非必要不XXX

4. 不要有单点

   系统中的单点可以说是系统架构上的一个大忌，因为单点意味着没有备份，风险不可控，我们设计分布式系统最重要的原则就是“消除单点”。

​ 越追求极致性能，系统定制开发就会越多，同时系统的通用性也就会越差。软件开发中有一句话是“细节是魔鬼”。

流量削峰怎么做

• 排队

  使用消息队列来缓存瞬间的峰值流量，把同步调用改成异步的调用，，中间通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去

• 答题

  一是防止部分买家使用秒杀器在参加秒杀时作弊第二个目的其实就是延缓请求。秒杀答题的逻辑主要分为 3 部分。

• 分层过滤

  分层校验的目的是：在读系统中，尽量减少由于一致性校验带来的系统瓶颈，但是尽量将不影响性能的检查条件提前，如用户是否具有秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束、是否非法请求、营销等价物是否充足等；在写数据系统中，主要对写的数据（如“库存”）做一致性检查，最后在数据库层保证数据的最终准确性（如“库存”不能减为负数）。

秒杀的一种实现方案

1. 提前设置好秒杀商品缓存
2. 前端限流，3秒内只提交一个请求，静态资源存放于 CDN。
3. 后端 redis 对 uid 限流，同样 3 秒内提交一个请求。
4. 请求保存队列，队列长度为库存 2 倍。防止前面预订失败，后面补上。
5. 队列满后，后续请求直接返回秒杀结束。
6. 消费线程消费队列内容，下订单，直接操作 MySQL 扣库存。