一、什么是秒杀系统

秒杀系统不一定有海量数据，比如12306的抢票，双十一的大促，可能票和商品就那么几千几万个而已，但是他的并发读写很高，在同一时刻会涌入大量的读写请求，会造成大量的锁冲突。

二、如何解决秒杀
  • 降读
  • 降写
  • 从产品下手
三、降读

用缓存，nginx+lua+redis+jvm内存等多级缓存，cdn缓存等。
用限流熔断组件。

如果有时间的话后期完善。

四、降写

比如下单场景，点了下卡住了，你着急就一直点击下单，或者抢购，这样不可能让客户端一直发请求到服务端，所以如下策略：

  • 1.浏览器/APP客户端上的请求拦截（比如：js限制用户1s内只能点1下等）
  • 2.站点的请求拦截（比如：针对某个用户id做限流，5s内只能写一次，如果频繁写则返回错误页或者将页面缓存到内存，5s内同用户访问的页面都一样，直接从内存取，不查db）
  • 3.服务层的请求拦截（比如：黑客抓了1w个肉鸡，也就是userid，然后去刷你，这时候就需要服务端做拦截了，两种方案：1.如果是库存有限制，比如1000个，那么直接放一千个请求过去就行了，因为放多了也是无效请求。一千以后的请求直接返回卖光了就行了。2.如果没库存限制或者库存几千万几百万级别的，那么压测db，看看每秒能支持多少读写，比如2000，那么放1800左右的请求进去就好了，别把服务压垮，否则db层一直雪崩，起来就被压垮。这个请求数可以是mq控制也可以自己内存里的队列控制，咋都行）。
  • 4.数据库层，如果是秒杀业务，这个不需要做任何，弄个高可用就行了，因为库存一共几百几千个数据，服务端层还做了限流，可以保障进来的请求都是有效请求（无效请求：进来后发现库存没了，白扯），所以压力不大。
五、从产品下手

几个典型的案例：

  • 下单与支付分离

下单和支付放到两个步骤里，能够降低数据库的写压力，比如12306，下单成功后，系统占住库存，15分钟之内支付即可。

  • 地域用户规则不同

不同地区的售票开放点不同，比如北京8点售票，上海八点半开始，深圳九点开始，这样能够分担系统压力。

  • 按钮只能点一次

点击提交订单，系统压力较大，返回迟缓，用户心里着急就一直点点点，也会对系统造成压力，所以直接置灰。

  • 库存不显示数量

只显示有票/无票，而不显示剩余几张，这样能够降低缓存淘汰率，因为每次更新库存都要淘汰缓存，只显示有无的话只需要淘汰一次。