1 秒杀场景

秒杀场景

  1. 登陆12306进行火车票抢座

  2. 1599元购入飞天茅台

  3. 周董演唱会的门票

  4. 双十一秒杀活动

秒杀场景关注点

  1. 严格防止超卖:库存1000件卖了1020件,要杀个码农祭天了!防止超卖是秒杀系统设计最核心的部分。
  2. 防止黑产:防止不怀好意的羊毛党薅羊毛。

  3. 保证用户体验:高并发下,给用户提供友善的购物体验,尽可能支持比较高的QPS等等。

接下来就让我们按照关注点,不断细化秒杀场景。

2 第1版-裸奔

不加思考,上来直接按照 SpringBoot + MyBatis 模式进行秒杀系统的设计,流程如下:

  1. Controller层获得用户秒杀请求后调用Service层。

  2. Service层获得请求后要要检查已售数据跟库存总量是否一致,一致说明商品卖没了,不一致说明还有库存,那就调用DAO层对已售数量进行加1。

  3. DAO层获得请求后直接通过MyBatis操作数据库实现已售数量加1跟订单创建。

如果你用Postman去测试会发现是OK的,但如果你用专业的并发测试工具JMeter模式多用户并发请求会发现订单创建数量 > 库存量 - 已售量。原因解释下,比如用户A、B并发进行秒杀请求,此时库存=100,已售=64。

  1. A用户进行描述请求,此时调用到了Service层,发现已售不等于库存,此时拿到库存数是64,A将库存更新为63,然后创建订单。

  2. B用户进行描述请求,此时调用到了Service层,发现已售不等于库存,此时拿到库存数是64,B将库存更新为63,然后创建订单。

  3. 此时库存减少了1个但是订单创建多个,卖超了!

3 第2版-悲观锁

遇见 并发问题 很容易想到以前学过并发编程嘛,既然Controller默认是单例模式,那我用 synchronized 将Controller层调用Service层的代码进行加锁同步即可。

这样就可以解决卖超问题了,但是须知,既然是悲观锁,如果有1000个并发请求,那只有1个拿到锁了。有999个会去竞争这个锁的。

当然了你也可以用Spring自带的事务注解来实现悲观锁的操作,因为用了@Transactional就可以实现通过事务来控制,要么全部成功,要么全部失败,用事务时有两点需注意:

  1. 尽可能将MySQL执行语句往方法体后面靠,因为MySQL事务的commit语句是在第一次执行MySQL相关语句开始,一直到方法的结束。

  2. 设置事务的超时时间,如果不设置默认是-1是无限长。并且事务中设置的耗时timeout = 最后一个MySQL语句耗时 + 以及最后一个MySQL之前的所有耗时。

需注意:悲观锁状态下会保证商品卖出去,如果没拿到锁的线程会阻塞的等待拿锁。但是他的阻塞也会给用户带来非常不良好的体验

4 第3版-乐观锁

我们为每个数量的已售数据配备个版本号,在Service层调用时获得用户的已售数跟对应版本号,然后更新时将已售数跟版本号同时更新。因为 MySQL在更新时会自带乐观加速机制,如果更新成功则表示抢购成功,更新失败则表示抢购失败,此时你会发现不是手速越快就一定能抢到的哦,但起码保证了不会超卖,

需注意:乐观锁状态下,由于是随机性的秒杀失败,所以可能活动结束后还会有几个没售出去的!

5 第4版-限流

最核心的超卖问题已经解决了,接下来就是各种优化手段了。在高并发请求中如果不对接口限流会对后台服务器造成极大压力,所以一般秒杀系统为了不影响其他业务会单独部署到个某个服务器上,同时还会设置好限流。

常用的限流方法有我们在 Redis 中曾经说过,主要有漏桶算法令牌桶算法。而Google开源项目GuavaRateLimiter使用的就是令牌桶控制算法。在开发高并发系统时有三把利器用来保护系统:缓存降级限流

  1. 缓存:缓存的目的是提升系统访问速度和增大系统处理容量。

  2. 降级:降级是当服务器压力剧增的情况下,根据当前业务情况及流量对一些服务和页面有策略的降级,以此释放服务器资源以保证核心任务的正常运行。

  3. 限流:限流的目的是通过对并发访问/请求进行限速,或者对一个时间窗口内的请求进行限速来保护系统,一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理。

5.1 漏桶算法

漏桶算法思路:把水比作是请求,漏桶比作是系统处理能力极限,水先进入到漏桶里,漏桶里的水按一定速率流出,当流出的速率小于流入的速率时,由于漏桶容量有限,后续进入的水直接溢出(拒绝请求),以此实现限流。

5.2 令牌桶算法

令牌桶算法原理:可以理解成医院的挂号看病,只有拿到号以后才可以进行诊病。

流程大致

  1. 所有的请求在处理之前都需要拿到一个可用的令牌才会被处理。

  2. 根据限流大小,设置按照一定的速率往桶里添加令牌。

  3. 设置桶最大可容纳值,当桶满时新添加的令牌就被丢弃或者拒绝。

  4. 请求达到后首先要获取令牌桶中的令牌,拿着令牌才可以进行其他的业务逻辑,处理完业务逻辑之后,将令牌直接删除。

  5. 如果用户无法获得令牌可以选择一直阻塞等待,也可以选择设置好timeout机制。

  6. 令牌桶有最低限额,当桶中的令牌达到最低限额的时候,请求处理完之后将不会删除令牌,以此保证足够的限流。

工程中一般用令牌桶算法为多,一般用GoogleGuava 中 RateLimiter 即可。

6 第5版- 细节优化

有了乐观锁跟限流,接下来再思考写细节问题。

  1. 秒杀要有时间范围限制的,不能再任意时刻都可以接受秒杀请求,要实行限时抢购

  2. 如果有懂IT人员通过抓包获取了秒杀接口地址,在秒杀开始时,不通过按钮,直接通过脚本秒杀咋办?要实行秒杀接口隐藏

  3. 每个用户单位时间内访问次数要做频率限制

6.1 限时抢购

很简单,将秒杀商品放入Redis并设置超时,比如我们以kill + 商品id作为key,以商品id作为value,设置180秒超时。

加入时间校验:

6.2 秒杀接口隐藏

  1. 用户秒杀前先通过getMd5方法获得一个请求秒杀URL的MD5值。

  2. 请求getMd5算法,Key = 商品id + 用户id,value = 商品id + 用户id + 盐 。将KV存入redis并且设置过期时间,最终返回value作为md5值。

  3. 用户请求秒杀URL的时候需携带MD5值,然后Service层会根据商品id + 用户id从redis中获取下对应的value,看这个value跟MD5值是否一致,绝对下一步操作。

    此时如果用户直接请求秒杀接口就会被限制了,但如果黑客技术升级,将请求MD5跟请求秒杀接口写到一起,还是无法防止被薅羊毛!咋办呢?再限制下用户访问频率

6.3 访问频率限制

  1. 通过前面请求后根据用户id生成个redis中的key,value为访问次数,默认为0,并且设置好该KV的过期时间。

  2. 用户在验证是否通过秒杀隐藏接口验证前,先看下他的单位时间内访问次数是多少,如果超过阈值则直接拒绝,没超过再进行隐藏接口的验证。

  3. 这里只是举例为用户访问次数限制,IP访问次数限制类似。

    7 第6版-众多细节优化

  1. CDN加速:为何京东物流快,因为人在全国各地配置了多个仓库。同理,我们可以将前端的一些静态东西配置在全国各个不同的地方,用户请求时,直接请求距离自己最近的前端资源即可。

  2. 前端按钮灰色化:如果参与过秒杀活动会发现,没到秒杀时间时秒杀按钮是灰色状态的,只有时间到了才是可点击状态。并且秒杀开始咯也不是一直可以点的,可能只允许1秒内点10次那种的。

  3. Nginx负载均衡:一个tomcat的QPS一般在200~1000左右,如果淘宝或京东性质的秒杀,就需要搞个Nginx负载均衡来支持几万级别的并发了。

  4. 信息存储Redis化:单独的MySQL是无法支撑上万的QPS的,既然Redis号称可支持10W级的QPS,我们把数据信息存到Redis中就好咯嘛!有人可能会说MySQL有乐观锁跟事务性啊,Redis不是没有事务性么,其实我们可以通过 Lua 脚本来实现并发情况下Redis的事务性操作。

  5. 消息中间件-流量削峰:秒杀成功后,如果秒杀的成功量过大,全部订单直接写入MySQL也是不太恰当的,可以把秒杀成功的用户信息写入消息中间件。比如RabbitMQ、Kafka,给用户返回抢购成功信息,然后专门代码消费中间件信息(生成订单,数据持久化),因为是异步消费,为防止用户秒杀成功后无法看到订单信息,在订单生成前给用户提示订单提交排队中,啥时候订单异步消费成功了再告知用户成功。

  6. 辅助手段:秒杀前做个预演练是必须的吧,系统上线后QPS监控、CPU监控、IO监控、缓存监控也是必须要搞的。同时一旦服务真的扛不住了熔断跟限流也要考虑进去。

  7. 短URL:有时你别人发给你个超短的URL你打开后就直接跳转为日常看到的购物页面了,这就涉及到短URL映射了,大致思路就是做个链接映射,在此基础上也可以玩出各种花样。

  8. 工业化秒杀:真正工业化的秒杀绝对不止我前面说的那么简单哦,起码你会接触到 MQSpringBootRedisDubboZK 、Mavenlua等知识点

架构师之路(18)讲解秒杀系统设计相关推荐

  1. 架构师之路18年精选100篇

    架构师之路,2018精选索引,以方便大家查询. [分布式架构] <架构,为什么要做服务化?> <架构,如何进行容量设计?> <架构,关于负载均衡的一切> <架 ...

  2. Java架构师之路——Java中高阶知识精讲-银文杰-专题视频课程

    Java架构师之路--Java中高阶知识精讲-4372人已学习 课程介绍         Java架构师除了对软件顶层结构进行设计和搭建外,还需要负责对软件核心基础的模块进行代码开发,而掌握Java中 ...

  3. java架构师之路:JAVA程序员必看的15本书的电子版下载地址

    java架构师之路:JAVA程序员必看的15本书的电子版下载地址 作为Java程序员来说,最痛苦的事情莫过于可以选择的范围太广,可以读的书太多,往往容易无所适从.我想就我自己读过的技术书籍中挑选出来一 ...

  4. 架构师之路17年精选80篇

    [架构必备] <互联网架构如何实现"高并发">4W+ <TCP接入层的负载均衡.高可用.扩展性架构设计>2.2W+ <配置中心架构设计演进>1. ...

  5. python爬虫架构师之路_一位资深 架构师大牛给予Java技术提升的学习路线建议

    一位资深 架构师大牛给予Java技术提升的学习路线建议 对于工作多年的程序员而言,日后的职业发展无非是继续专精技术.转型管理和晋升架构师三种选择. 架构师在一家公司有多重要.优秀架构师需要具备怎样的素 ...

  6. Java高级架构师之路核心知识整理

    小编整理出一篇Java高级架构师之路的核心知识,同时也是面试时面试官必问的知识点,篇章也是包括了很多知识点,其中包括了有基础知识.Java集合.JVM.多线程并发.spring原理.微服务.Netty ...

  7. 架构师之路 - OSGI for C++

    作者: 一去.二三里 个人微信号: iwaleon 微信公众号: 高效程序员 课程介绍 OSGI 技术是面向 Java 的动态模型系统.Java 圈子里有非常著名的一句话:OSGI - 架构师的天堂. ...

  8. 架构师之路,2020半年精选!!!

    不知不觉,2020年已经过了一半了.今天,架构师之路,简单做个总结,如果错过一些好文,这是一个补票的好机会.点击标题,直接阅读. 架构实践: <究竟如何保证,session一致性?> &l ...

  9. 典型数据库架构设计与实践 | 架构师之路

    转载自微信公众号[架构师之路] 本文,将介绍数据库架构设计中的一些基本概念,常见问题以及对应解决方案,为了便于读者理解,将以"用户中心"数据库为例,讲解数据库架构设计的常见玩法. ...

最新文章

  1. 让Redis突破内存大小的限制
  2. 苹果x可以双卡吗_苹果12支持双卡吗
  3. android图片编解码architecture
  4. 计算机网络基础第九章简答题,计算机网络技术基础课后习题答案.doc
  5. string的compare operator
  6. 【渝粤教育】国家开放大学2018年春季 0603-22T建筑工程管理与实务 参考试题
  7. Camera 初始化(Preview) 二(HAL3的流程)
  8. php tcp获取数据_php建立tcp服务请求数据双向通信问题
  9. AD14如何设置指定线路与敷铜之间的安全距离
  10. vue实现画出页面二维码的3种办法
  11. android 中文冒号,Kotlin中双冒号::使用方法
  12. Elasticsearch 最佳运维实践总结
  13. Linux主目录文件夹英文,中文Ubuntu主目录下的文件夹改回英文
  14. 亮剑java web_为什么《亮剑Java Web 项目开发案例导航》第二个项目运行不了?
  15. MySQL主从之GTID主从
  16. 如何使用poi解析word生成html目录结构
  17. mysql error unpacking_error: unpacking of archive failed on file错误的解决
  18. 常用免费文献下载平台
  19. 时间的朋友——观后感
  20. 谨慎程序员创业的思维障碍

热门文章

  1. CMD权限不够怎么办
  2. ios浏览器打开app页面提示“浏览器打不开该网页,因为网址无效”
  3. Flink1.11 读取kafka数据写入hive,未完待续
  4. java B2B2C Springcloud电子商务平台源码------Hystrix的缓存使用
  5. 可使用计算机打印的方式替代,邮政投递员高级理论知识试卷02
  6. 常用的dns地址分享
  7. Mac M2芯 超详细k8s集群实战 - kubeadm
  8. 用天然气做燃料极空气做氧化极的燃料电池
  9. 2008年超级计算机排名,2008年Opteron超级计算机性能将突破1petaflop
  10. 知识图谱:SPARQL的基本语法示例