1 秒杀场景秒杀场景登陆12306进行火车票抢座1599元购入飞天茅台周董演唱会的门票双十一秒杀活动秒杀场景关注点严格防止超卖库存1000件卖了1020件要杀个码农祭天了防止超卖是秒杀系统设计最核心的部分。防止黑产防止不怀好意的羊毛党薅羊毛。保证用户体验高并发下给用户提供友善的购物体验尽可能支持比较高的QPS等等。接下来就让我们按照关注点不断细化秒杀场景。2 第1版-裸奔裸奔秒杀不加思考上来直接按照SpringBoot MyBatis模式进行秒杀系统的设计流程如下Controller层获得用户秒杀请求后调用Service层。Service层获得请求后要要检查已售数据跟库存总量是否一致一致说明商品卖没了不一致说明还有库存那就调用DAO层对已售数量进行加1。DAO层获得请求后直接通过MyBatis操作数据库实现已售数量加1跟订单创建。如果你用Postman去测试会发现是OK的但如果你用专业的并发测试工具JMeter模式多用户并发请求会发现订单创建数量库存量 - 已售量。原因解释下比如用户A、B并发进行秒杀请求此时库存100已售64。A用户进行描述请求此时调用到了Service层发现已售不等于库存此时拿到库存数是64A将库存更新为63然后创建订单。B用户进行描述请求此时调用到了Service层发现已售不等于库存此时拿到库存数是64B将库存更新为63然后创建订单。此时库存减少了1个但是订单创建多个卖超了无锁并发请求卖超了3 第2版-悲观锁syn悲观锁遇见 并发问题 很容易想到以前学过并发编程嘛既然Controller默认是单例模式那我用 synchronized 将Controller层调用Service层的代码进行加锁同步即可。这样就可以解决卖超问题了但是须知既然是悲观锁如果有1000个并发请求那只有1个拿到锁了。有999个会去竞争这个锁的。Transactional Service Transactional Slf4j public class OrderServiceImpl implements OrderService { //校验库存 Stock stock checkStock(id); //更新库存 updateSale(stock); //创建订单 return createOrder(stock); }当然了你也可以用Spring自带的事务注解来实现悲观锁的操作因为用了Transactional就可以实现通过事务来控制要么全部成功要么全部失败用事务时有两点需注意尽可能将MySQL执行语句往方法体后面靠因为MySQL事务的commit语句是在第一次执行MySQL相关语句开始一直到方法的结束。设置事务的超时时间如果不设置默认是-1是无限长。并且事务中设置的耗时timeout 最后一个MySQL语句耗时 以及最后一个MySQL之前的所有耗时。需注意悲观锁状态下会保证商品卖出去如果没拿到锁的线程会阻塞的等待拿锁。但是他的阻塞也会给用户带来非常不良好的体验。4 第3版-乐观锁MySQL版本号我们为每个数量的已售数据配备个版本号在Service层调用时获得用户的已售数跟对应版本号然后更新时将已售数跟版本号同时更新。因为 MySQL在更新时会自带乐观加速机制如果更新成功则表示抢购成功更新失败则表示抢购失败此时你会发现不是手速越快就一定能抢到的哦但起码保证了不会超卖update 库存表 set 已售数已售数1,版本号版本号1 where 秒杀id #{id} and 版本号 #{version}需注意乐观锁状态下由于是随机性的秒杀失败所以可能活动结束后还会有几个没售出去的5 第4版-限流最核心的超卖问题已经解决了接下来就是各种优化手段了。在高并发请求中如果不对接口限流会对后台服务器造成极大压力所以一般秒杀系统为了不影响其他业务会单独部署到个某个服务器上同时还会设置好限流。常用的限流方法有我们在 Redis 中曾经说过主要有漏桶算法、令牌桶算法。而Google开源项目Guava中RateLimiter使用的就是令牌桶控制算法。在开发高并发系统时有三把利器用来保护系统缓存、降级、限流缓存缓存的目的是提升系统访问速度和增大系统处理容量。降级降级是当服务器压力剧增的情况下根据当前业务情况及流量对一些服务和页面有策略的降级以此释放服务器资源以保证核心任务的正常运行。限流限流的目的是通过对并发访问/请求进行限速或者对一个时间窗口内的请求进行限速来保护系统一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理。5.1 漏桶算法漏桶算法思路把水比作是请求漏桶比作是系统处理能力极限水先进入到漏桶里漏桶里的水按一定速率流出当流出的速率小于流入的速率时由于漏桶容量有限后续进入的水直接溢出拒绝请求以此实现限流。5.2 令牌桶算法令牌桶算法原理可以理解成医院的挂号看病只有拿到号以后才可以进行诊病。流程大致所有的请求在处理之前都需要拿到一个可用的令牌才会被处理。根据限流大小设置按照一定的速率往桶里添加令牌。设置桶最大可容纳值当桶满时新添加的令牌就被丢弃或者拒绝。请求达到后首先要获取令牌桶中的令牌拿着令牌才可以进行其他的业务逻辑处理完业务逻辑之后将令牌直接删除。如果用户无法获得令牌可以选择一直阻塞等待也可以选择设置好timeout机制。令牌桶有最低限额当桶中的令牌达到最低限额的时候请求处理完之后将不会删除令牌以此保证足够的限流。工程中一般用令牌桶算法为多一般用Google的Guava中RateLimiter即可。//创建令牌桶实例 private RateLimiter rateLimiter RateLimiter.create(20); // 阻塞式获得令牌才继续往下执行 rateLimiter.acquire(); // 就等3秒看是否可以获得令牌返回Boolean值。 rateLimiter.tryAcquire(3, TimeUnit.SECONDS)6 第5版- 细节优化有了乐观锁跟限流接下来再思考写细节问题。秒杀要有时间范围限制的不能再任意时刻都可以接受秒杀请求要实行限时抢购。如果有懂IT人员通过抓包获取了秒杀接口地址在秒杀开始时不通过按钮直接通过脚本秒杀咋办要实行秒杀接口隐藏。每个用户单位时间内访问次数要做频率限制。6.1 限时抢购很简单将秒杀商品放入Redis并设置超时比如我们以kill 商品id作为key以商品id作为value设置180秒超时。127.0.0.1:6379 set kill1 1 EX 180 OK加入时间校验public Integer createOrder(Integer id) { //redis校验抢购时间 if(!stringRedisTemplate.hasKey(kill id)){ throw new RuntimeException(秒杀超时,活动已经结束啦!!!); } //校验库存 Stock stock checkStock(id); //扣库存 updateSale(stock); //下订单 return createOrder(stock); }6.2 秒杀接口隐藏接口隐藏用户秒杀前先通过getMd5方法获得一个请求秒杀URL的MD5值。请求getMd5算法Key 商品id 用户idvalue 商品id 用户id 盐 。将KV存入redis并且设置过期时间最终返回value作为md5值。用户请求秒杀URL的时候需携带MD5值然后Service层会根据商品id 用户id从redis中获取下对应的value看这个value跟MD5值是否一致绝对下一步操作。// 根据商品id 跟 用户id生成个md5。 Override public String getMd5(Integer id, Integer userid) { //检验用户的合法性 User user userDAO.findById(userid); if(usernull)throw new RuntimeException(用户信息不存在!); //检验商品的合法行 Stock stock stockDAO.checkStock(id); if(stocknull) throw new RuntimeException(商品信息不合法!); String hashKey KEY_ userid _ id; //生成md5此处的 !AW# 是一个盐可以跟找个Random随机生成。 String key DigestUtils.md5DigestAsHex((userid id !AW#).getBytes()); stringRedisTemplate.opsForValue().set(hashKey, key, 3600, TimeUnit.SECONDS); return key; }此时如果用户直接请求秒杀接口就会被限制了但如果黑客技术升级将请求MD5跟请求秒杀接口写到一起还是无法防止被薅羊毛咋办呢再限制下用户访问频率。6.3 访问频率限制通过前面请求后根据用户id生成个redis中的keyvalue为访问次数默认为0并且设置好该KV的过期时间。用户在验证是否通过秒杀隐藏接口验证前先看下他的单位时间内访问次数是多少如果超过阈值则直接拒绝没超过再进行隐藏接口的验证。这里只是举例为用户访问次数限制IP访问次数限制类似。秒杀源码公众号回复秒杀获取。访问频率限制7 第6版-众多细节优化CDN加速为何京东物流快因为人在全国各地配置了多个仓库。同理我们可以将前端的一些静态东西配置在全国各个不同的地方用户请求时直接请求距离自己最近的前端资源即可。前端按钮灰色化如果参与过秒杀活动会发现没到秒杀时间时秒杀按钮是灰色状态的只有时间到了才是可点击状态。并且秒杀开始咯也不是一直可以点的可能只允许1秒内点10次那种的。Nginx负载均衡一个tomcat的QPS一般在200~1000左右如果淘宝或京东性质的秒杀就需要搞个Nginx负载均衡来支持几万级别的并发了。信息存储Redis化单独的MySQL是无法支撑上万的QPS的既然Redis号称可支持10W级的QPS我们把数据信息存到Redis中就好咯嘛有人可能会说MySQL有乐观锁跟事务性啊Redis不是没有事务性么其实我们可以通过Lua脚本来实现并发情况下Redis的事务性操作。消息中间件-流量削峰秒杀成功后如果秒杀的成功量过大全部订单直接写入MySQL也是不太恰当的可以把秒杀成功的用户信息写入消息中间件。比如RabbitMQ、Kafka给用户返回抢购成功信息然后专门代码消费中间件信息(生成订单数据持久化)因为是异步消费为防止用户秒杀成功后无法看到订单信息在订单生成前给用户提示订单提交排队中啥时候订单异步消费成功了再告知用户成功。辅助手段秒杀前做个预演练是必须的吧系统上线后QPS监控、CPU监控、IO监控、缓存监控也是必须要搞的。同时一旦服务真的扛不住了熔断跟限流也要考虑进去。短URL有时你别人发给你个超短的URL你打开后就直接跳转为日常看到的购物页面了这就涉及到短URL映射了大致思路就是做个链接映射在此基础上也可以玩出各种花样反正挺有趣的(有兴趣可以水一篇)。秒杀大致流程图工业化秒杀真正工业化的秒杀绝对不止我前面说的那么简单哦起码你会接触到MQ、SpringBoot、Redis、Dubbo、ZK、Maven、lua等知识点我也从同性交友网站GitHub找到了份爆赞的工业化秒杀项目公众号回复秒杀就可以获取啦。