您现在的位置是：主页 > news > 网站上传修改限制吗/免费发布外链
网站上传修改限制吗/免费发布外链
admin2025/4/30 9:03:32【news】
简介网站上传修改限制吗,免费发布外链,网站建设的英文,建设网站需要哪些硬件前言 本文主要就电商秒杀系统所涉及的相关技术进行探究，相关Demo地址如下： 个人实现版本：https://github.com/MrSorrow/seckillGithub Star较高的版本，第一版也是基于慕课网的：https://github.com/qiurunze123/miaos…
网站上传修改限制吗,免费发布外链,网站建设的英文,建设网站需要哪些硬件前言
本文主要就电商秒杀系统所涉及的相关技术进行探究，相关Demo地址如下：
个人实现版本：https://github.com/MrSorrow/seckillGithub Star较高的版本，第一版也是基于慕课网的：https://github.com/qiurunze123/miaos…
前言
本文主要就电商秒杀系统所涉及的相关技术进行探究，相关Demo地址如下：
- 个人实现版本：https://github.com/MrSorrow/seckill
- Github Star较高的版本，第一版也是基于慕课网的：https://github.com/qiurunze123/miaosha
本Demo实现了电商项目的秒杀功能，主要内容包含了用户登录、浏览商品、秒杀抢购、创建订单等功能，着重解决秒杀系统的并发问题。项目利用JMeter工具进行压力测试，着重对比采用缓存、消息队列等手段对于提高系统响应速度并发能力的效果。
项目视频参考地址：https://www.bilibili.com/video/av50818180/
一、快速开始
「环境准备」
- 安装Docker;
- 安装MySQL的Docker环境 (注意设置容器时区和MySQL时区);
docker pull mysql:5.7.23 docker run --name e3-mall-mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=1234 -e TZ=Asia/Shanghai -d mysql:5.7.23 --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci --default-time_zone='+8:00' - 安装Redis的Docker环境;
docker pull redis:3.2 docker run -d -p 6379:6379 --name e3-mall-redis -e TZ=Asia/Shanghai redis:3.2 - 安装RabbitMQ的Docker环境;
docker pull rabbitmq:3.7-management docker run -d --name e3-mall-rabbitmq -p 5672:5672 -p 15672:15672 --hostname e3-mall-rabbitmq -e RABBITMQ_DEFAULT_VHOST=mq_vhost -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin -e TZ=Asia/Shanghai rabbitmq:3.7-management
「导入项目」
- 克隆本项目 https://github.com/MrSorrow/seckill
- 项目采用Maven构建;
- 通过IDEA直接以Maven方式导入项目即可。
二、功能实现
I. 用户模块
「建立用户表」
CREATE TABLE miaosha_user (id BIGINT(20) NOT NULL PRIMARY KEY COMMENT "用户ID，手机号码",nickname VARCHAR(255) NOT NULL COMMENT "昵称",password VARCHAR(32) DEFAULT NULL COMMENT "MD5(MD5(pass明文, 固定SALT), 随机SALT)",salt VARCHAR(10) DEFAULT NULL,head VARCHAR(128) DEFAULT NULL COMMENT "头像，云存储ID",register_date datetime DEFAULT NULL COMMENT "注册时间",last_login_date datetime DEFAULT NULL COMMENT "上一次登录时间",login_count int(11) DEFAULT '0' COMMENT "登录次数"
) ENGINE INNODB DEFAULT CHARSET=utf8mb4;
「两次MD5密码加密」
- 客户端登录时避免明文密码在网络中传输，所以进行客户端第一次MD5;
- MD5的密码传输至服务端时，需要随机生成salt进行二次MD5，保存salt和两次MD5结果至数据库中。
「分布式Session」
- UUID方式生成Token，Redis保存Token-User的键值信息模拟Session;
- 将Token写到Cookie中，设置Path为顶级域名之下。
「注册登录功能实现」
- 封装服务端响应对象
guo.ping.seckill.result.ServerResponse以及状态码消息对象guo.ping.seckill.result.CodeMsg; - 利用JSR-303注解校验参数，并自定义手机号校验注解
guo.ping.seckill.validator.IsMobile以及验证器guo.ping.seckill.validator.IsMobileValidator; - 实现用户登录，批量注册用户逻辑;
- 自定义方法参数解析器用于获取请求中包含的Token值，并查询Redis封装成User;
- 具体代码参考 Commits on May 3, 2019 和 Commits on May 5, 2019
II. 商品模块
「建立商品与订单表」
- 数据库表包含普通商品表、普通订单表，以及专门用于秒杀商品的秒杀商品表和秒杀订单表;
- 普通商品表：
CREATE TABLE goods (id BIGINT(20) NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT "商品id",goods_name VARCHAR(16) DEFAULT NULL COMMENT "商品名称",goods_title VARCHAR(64) DEFAULT NULL COMMENT "商品标题",goods_img VARCHAR(64) DEFAULT NULL COMMENT "商品图片",goods_detail LONGTEXT COMMENT "商品详情",goods_price DECIMAL(10, 2) DEFAULT '0.00' COMMENT "商品单价",goods_stock INT(11) DEFAULT 0 COMMENT "-1表示没有限制" ) ENGINE=INNODB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4; - 秒杀商品表：
CREATE TABLE miaosha_goods (id BIGINT(20) NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT "秒杀商品id",goods_id BIGINT(20) DEFAULT NULL COMMENT "商品id",miaosha_price DECIMAL(10, 2) DEFAULT '0.00' COMMENT "商品秒杀单价",stock_count INT(11) DEFAULT NULL COMMENT "库存数量",start_date DATETIME DEFAULT NULL COMMENT "秒杀开始时间",end_date DATETIME DEFAULT NULL COMMENT "秒杀结束时间" ) ENGINE=INNODB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4; - 普通订单表：
CREATE TABLE order_info (id BIGINT(20) NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT "订单id",user_id BIGINT(20) DEFAULT NULL COMMENT "用户id",goods_id BIGINT(20) DEFAULT NULL COMMENT "商品id",goods_name VARCHAR(16) DEFAULT NULL COMMENT "反范式冗余的商品名称",goods_count INT(11) DEFAULT '0' COMMENT "商品数量",goods_price DECIMAL(10, 2) DEFAULT '0.00' COMMENT "商品单价",delivery_addr_id BIGINT(20) DEFAULT NULL COMMENT "收货地址id",order_channel TINYINT(4) DEFAULT '0' COMMENT "1-pc，2-android，3-ios",status TINYINT(4) DEFAULT '0' COMMENT "订单状态 0-新建未支付，1-已支付，2-已发货，3-已收货，4-已退款，5-已完成",create_date DATETIME DEFAULT NULL COMMENT "创建订单时间",pay_date DATETIME DEFAULT NULL COMMENT "支付时间" ) ENGINE=INNODB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8mb4; - 秒杀订单表：
CREATE TABLE miaosha_order (id BIGINT(20) NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT "秒杀订单id",user_id BIGINT(20) DEFAULT NULL COMMENT "用户id",order_id BIGINT(20) DEFAULT NULL COMMENT "订单id",goods_id BIGINT(20) DEFAULT NULL COMMENT "商品id" ) ENGINE=INNODB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8mb4;
「展示商品列表及详情」
- 插入商品数据：
INSERT INTO goods VALUES (1, "iPhoneX", "Apple iPhone X (A1865) 64GB 深空灰色 移动联通电信4G手机", "/img/iphonex.png", "Apple iPhone X (A1865) 64GB 深空灰色 移动联通电信4G手机【五月特惠】大屏性价比iPhone7Plus4199元，iPhone8低至3499元，iPhoneXR低至4799元！更多特价、优惠券，点此查看！选移动，享大流量，不换号购机！", 5999, 100); INSERT INTO goods VALUES (2, "华为 P30", "华为 HUAWEI P30 Pro 超感光徕卡四摄10倍混合变焦麒麟980芯片屏内指纹", "/img/p30.png", "华为 HUAWEI P30 Pro 超感光徕卡四摄10倍混合变焦麒麟980芯片屏内指纹 8GB+256GB极光色全网通版双4G手机！", 5988, 55); INSERT INTO miaosha_goods VALUES (1, 1, 0.01, 4, NOW(), NOW()), (2, 2, 0.01, 9, NOW(), NOW()); - 通过连接普通商品表和秒杀商品表，查询出秒杀商品的全部信息;
- 将所有商品展示在
goods_list中，单个商品的全部信息展示在商品详情页goods_detail中。
「下单秒杀商品」
- 下单秒杀商品包含减少库存、创建订单两步，需要保证两步操作的原子性;
- 通过Spring声明式事务，保证减少库存、创建普通订单以及创建秒杀订单三步的原子性;
- 秒杀倒计时刷新由前端完成，后端仅仅在查看商品详情时返回一次计算的剩余时间即可，保证所有客户端的秒杀时间能够同步，以后端为准;
- 具体代码参考 Commits on May 6, 2019
三、 压测优化
I. 压力测试
利用JMeter对接口进行压测。压测文件保存在 preesure_test 文件夹下。
测试时MySQL、Redis连接池配置参数如下：
# druid pool config
druid:initial-size: 100max-active: 1000min-idle: 500max-wait: 5000
# redis pool config
redis:timeout: 5000lettuce:pool:max-active: 2000max-idle: 200max-wait: 3
由于设置的数据库连接池连接数量较大，需要对Docker-MySQL的最大连接数进行设置：
set GLOBAL max_connections=2000;
set GLOBAL max_user_connections=1500;
未采取任何优化措施前，部分核心接口测试性能如下：
| 压测接口 | 接口地址 | 线程数*循环次数 | 异常 % | 吞吐量 |
|---|---|---|---|---|
| 商品列表接口压测 | http://localhost:8080/goods/list | 5000*1 | 0.000% | 467.1 / sec |
| 单用户信息查询压测 | http://localhost:8080/user/info | 5000*1 | 0.000% | 996.9 / sec |
| 多用户秒杀接口压测 | http://localhost:8080/seckill/kill | 5000*1 | 0.000% | 289.8 / sec |
II. 性能优化
系统性能瓶颈在于MySQL的读写性能，所以主要利用各种技术减少对数据库层面的访问。
从缓存实现性能优化角度，用户的请求首先经过CDN优化，然后经过Nginx服务器缓存，再进入应用程序实现的页面级缓存，然后经过对象级缓存，最后可能经过数据库缓存。前面的层层缓存使得用户请求读写数据库的压力减小很多。
页面缓存优化技术包括：
- 页面缓存+URL缓存+对象缓存
- 页面静态化，前后端分离
- 静态资源优化
- CDN优化
以上是否通用接口的优化方式，针对秒杀场景，较短时间内大量的秒杀请求访问系统，根据其读多写少的业务特性，一旦商品秒杀结束，后续的秒杀请求一律返回秒杀失败即可，无需再访问缓存或数据库。
秒杀接口优化策略包括：
- Redis预减库存减少对数据库的访问，只有库存数量的请求才会真正访问数据库进行下单;
- 通过内存标记减少Redis访问。如果Redis预减库存已经减完，则之后的请求无需继续访问Redis继续预减;
- Redis放行的请求先进入消息队列进行缓冲，异步请求数据库下单，增强用户体验
其他提高系统并发能力的策略主要就是服务的水平复制与垂直拆分，构建分布式集群应用，通过多个节点分担压力，负载均衡等。
「模板引擎页面缓存」
- 页面缓存主要是指
Controller方法返回的不再是包含数据的Json，而是直接返回最终的HTML页面; - 通过页面模板引擎将
Service层得到的数据直接手动渲染页面，将整个页面缓存至Redis中; - 缓存的过期时间可以设定较短，保证用户看到的数据不至于过旧。
「模板引擎URL缓存」
- URL缓存主要是指针对不同的请求URL，缓存对应的HTML页面，基本和页面缓存相似;
- 通过以不同的URL为缓存的键来存储不同的页面;
- 同样缓存的淘汰策略也是自动过期。
「对象缓存」
- 对象缓存主要是指将
Service层得到的数据存入Redis中，这样每次请求先进行缓存查询，如果命中则直接返回; - 对象缓存一般没有变化则常驻于缓存，或设置较久的过期时间。数据在更新时，需要对缓存进行处理，往往先更新数据库，再删除缓存。
「页面静态化」
- 主要针对商品详情页，可以采取页面静态化的方式，直接生成静态HTML页面，保存在本地，额外用高性能HTTP服务器进行访问;
- 页面静态化方式可以使得前后端分离，一种方式是后端只提供RESTful API接口，前端编写半静态页面，通过Ajax获取数据再进行页面填充;
- 另一种页面静态化方式可以直接在添加商品时，利用页面模板引擎生成完全静态的商品详情网页，如果数据更改再重新生成新的页面。
「浏览器缓存」
通过浏览器端的缓存，可以降低对服务器的访问次数。Spring Boot对于静态资源的浏览器缓存相关配置如下：
# SPRING RESOURCES HANDLING (ResourceProperties)
spring.resources.add-mappings=true # Whether to enable default resource handling.
spring.resources.cache.cachecontrol.cache-private= # Indicate that the response message is intended for a single user and must not be stored by a shared cache.
spring.resources.cache.cachecontrol.cache-public= # Indicate that any cache may store the response.
spring.resources.cache.cachecontrol.max-age= # Maximum time the response should be cached, in seconds if no duration suffix is not specified.
spring.resources.cache.cachecontrol.must-revalidate= # Indicate that once it has become stale, a cache must not use the response without re-validating it with the server.
spring.resources.cache.cachecontrol.no-cache= # Indicate that the cached response can be reused only if re-validated with the server.
spring.resources.cache.cachecontrol.no-store= # Indicate to not cache the response in any case.
spring.resources.cache.cachecontrol.no-transform= # Indicate intermediaries (caches and others) that they should not transform the response content.
spring.resources.cache.cachecontrol.proxy-revalidate= # Same meaning as the "must-revalidate" directive, except that it does not apply to private caches.
spring.resources.cache.cachecontrol.s-max-age= # Maximum time the response should be cached by shared caches, in seconds if no duration suffix is not specified.
spring.resources.cache.cachecontrol.stale-if-error= # Maximum time the response may be used when errors are encountered, in seconds if no duration suffix is not specified.
spring.resources.cache.cachecontrol.stale-while-revalidate= # Maximum time the response can be served after it becomes stale, in seconds if no duration suffix is not specified.
spring.resources.cache.period= # Cache period for the resources served by the resource handler. If a duration suffix is not specified, seconds will be used.
spring.resources.chain.cache=true # Whether to enable caching in the Resource chain.
spring.resources.chain.compressed=false # Whether to enable resolution of already compressed resources (gzip, brotli).
spring.resources.chain.enabled= # Whether to enable the Spring Resource Handling chain. By default, disabled unless at least one strategy has been enabled.
spring.resources.chain.html-application-cache=false # Whether to enable HTML5 application cache manifest rewriting.
spring.resources.chain.strategy.content.enabled=false # Whether to enable the content Version Strategy.
spring.resources.chain.strategy.content.paths=/** # Comma-separated list of patterns to apply to the content Version Strategy.
spring.resources.chain.strategy.fixed.enabled=false # Whether to enable the fixed Version Strategy.
spring.resources.chain.strategy.fixed.paths=/** # Comma-separated list of patterns to apply to the fixed Version Strategy.
spring.resources.chain.strategy.fixed.version= # Version string to use for the fixed Version Strategy.
spring.resources.static-locations=classpath:/META-INF/resources/,classpath:/resources/,classpath:/static/,classpath:/public/ # 静态资源路径
「静态资源优化」
- 对JS/CSS文件压缩，减少流量;
- 多个JS/CSS进行组合为一个文件，减少请求资源时建立的TCP连接数;
- 利用WebPack可以进行前端资源打包。
「CDN就近访问优化」
- CDN：内容分发网络(Content Delivery Network)，CDN系统能够实时的根据网络流量和各节点的连接、负载情况选择从最近的节点将数据返回给用户;
- 购买现有的如阿里云CDN，腾讯CDN，百度CDN等等服务。
「消息队列削峰」
- 系统初始化，把商品库存数量加载到Redis中;
- 当用户进行秒杀请求时，Redis预减库存，如果库存不足，可以直接返回商品秒杀完成;
- 如果还有库存，则用户所有的秒杀请求全部进入消息队列，页面先显示排队中;
- 秒杀请求出队，减少数据库中的库存并生成秒杀订单;
- 客户端则需要通过js不断轮询是否秒杀成功，轮询方式为查询Redis中是否有订单记录以及Redis中设置的秒杀活动是否结束标记。
III. 安全优化
针对秒杀活动的安全问题，需要防止用户使用工具刷秒杀地址，所以需要隐藏秒杀接口地址，秒杀地址依靠请求服务端返回。加入验证码机制也可以防止机器人恶意刷新，同时限制瞬时请求数量。后端相关服务进行限流，限制用户一段时间内的最高访问次数。
「隐藏秒杀接口」
- 秒杀抢购时，先请求服务端生成随机的秒杀地址，服务端缓存随机秒杀地址用于校验；
- 然后再通过请求拿到的随机秒杀地址，服务端先进行校验(和缓存对比)，再决定是否进行秒杀商品。
「接口限流防刷」
- 利用Redis记录用户对于某个请求的一段时间内的访问次数;
- 如果超时，Redis对于某个请求的访问次数缓存会失效(重新计时);
- 自定义限流注解
@AccessLimit，利用Spring提供的拦截器对每一个请求方法进行判断，是否包含限流注解。
四、打包部署
I. 项目打包
- 将Spring Boot项目打包成Jar包，指定打包路径和打包名称;
<build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId></plugin></plugins><finalName>seckill-springboot</finalName><directory>/Users/guoping/Projects/Intelljidea/seckill/seckill/</directory> </build> - 编写Dockerfile构建镜像，参考官方文档;
# 基础镜像 FROM java:8 # 挂载点为/tmp，jar包就会存在这里 VOLUME /tmp # 拷贝打包好的jar包 COPY seckill-springboot.jar seckill-springboot.jar # 暴露端口 EXPOSE 8080 # 容器创建后执行jar ENTRYPOINT ["java","-jar","/seckill-springboot.jar"] - 构建镜像创建实例并运行服务;
docker build -t guoping/seckill:1.0 . docker run -d -p 80:8080 --name e3-mall-seckill guoping/seckill:1.0 - 测试服务。
II. 水平复制
- 启动3个实例，分别端口映射到宿主机的8081、8082、8083，打开宿主机防火墙;
docker run -d -p 8081:8080 --name e3-mall-seckill-1 -e TZ=Asia/Shanghai guoping/seckill:1.0 docker run -d -p 8082:8080 --name e3-mall-seckill-2 -e TZ=Asia/Shanghai guoping/seckill:1.0 docker run -d -p 8083:8080 --name e3-mall-seckill-3 -e TZ=Asia/Shanghai guoping/seckill:1.0 - 利用Nginx进行反向代理，宿主机上传好
nginx.conf配置文件，其中配置好多节点负载均衡;events {worker_connections 6000; }.......upstream e3-mall-seckill-servers {server 192.168.2.113:8081 weight=1;server 192.168.2.113:8082 weight=1;server 192.168.2.113:8083 weight=1; }server {listen 80;server_name localhost;location / {proxy_pass http://e3-mall-seckill-servers;index index.html index.htm;} } - 下载Nginx镜像，创建实例反向代理Nginx服务器。
docker pull nginx docker run --name e3-mall-nginx -v /root/nginx.conf:/etc/nginx/nginx.conf:ro -p 80:80 -d -e TZ=Asia/Shanghai nginx
[root@localhost ~]# ls
anaconda-ks.cfg Dockerfile seckill-springboot.jar
[root@localhost ~]# docker build -t guoping/seckill:1.0 .
Sending build context to Docker daemon 38.35MB
Step 1/5 : FROM java:8
8: Pulling from library/java
5040bd298390: Pull complete
fce5728aad85: Pull complete
76610ec20bf5: Pull complete
60170fec2151: Pull complete
e98f73de8f0d: Pull complete
11f7af24ed9c: Pull complete
49e2d6393f32: Pull complete
bb9cdec9c7f3: Pull complete
Digest: sha256:c1ff613e8ba25833d2e1940da0940c3824f03f802c449f3d1815a66b7f8c0e9d
Status: Downloaded newer image for java:8---> d23bdf5b1b1b
Step 2/5 : VOLUME /tmp---> Running in c846eebffe0c
Removing intermediate container c846eebffe0c---> 11169eefdf99
Step 3/5 : COPY seckill-springboot.jar seckill-springboot.jar---> b4c86a1b8ade
Step 4/5 : EXPOSE 8080---> Running in 3215803d2ea8
Removing intermediate container 3215803d2ea8---> ceaab0ec1c5d
Step 5/5 : ENTRYPOINT ["java","-jar","/seckill-springboot.jar"]---> Running in a27bb88d19d4
Removing intermediate container a27bb88d19d4---> b184325f919e
Successfully built b184325f919e
Successfully tagged guoping/seckill:1.0
[root@localhost ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
guoping/seckill 1.0 b184325f919e 9 seconds ago 682MB
mysql 5.7.23 1b30b36ae96a 6 months ago 372MB
redis 3.2 87856cc39862 6 months ago 76MB
java 8 d23bdf5b1b1b 2 years ago 643MB
[root@localhost ~]# docker run -d -p 80:8080 --name e3-mall-seckill guoping/seckill:1.0
8ff680628f8434f4c8318061188c722d87655293f75957551f6bd87e159c4abc
[root@localhost ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8ff680628f84 guoping/seckill:1.0 "java -jar /seckill-…" 4 minutes ago Up 4 minutes 0.0.0.0:80->8080/tcp e3-mall-seckill
dd194cf5bad6 mysql:5.7.23 "docker-entrypoint.s…" 23 hours ago Up 23 hours 0.0.0.0:3306->3306/tcp, 33060/tcp e3-mall-mysql
1a244491f479 redis:3.2 "docker-entrypoint.s…" 8 days ago Up 8 days 0.0.0.0:6379->6379/tcp e3-mall-redis
五、实现细节
I. 数据库连接问题
当对接口进行压测时，瞬时启动5000个线程去请求接口。我们查看MySQL容器日志时发现，无法创建数据库连接，如下所示。
这是由于我们在 application.yaml 中配置了1000个数据库连接请求，默认的MySQL容器最大连接数根本没有这么多，只有151。
可以通过下面SQL语句查询数据库最大连接数。更改最大连接数目用下面两个SQL语句即可，但缺点是MySQL重启即会失效。
show global variables like "max%connections";
set GLOBAL max_connections=2000;
set GLOBAL max_user_connections=1500;
设置结果如下所示：
设置完成后，MySQL容器便不会报错，同时可以发现系统启动时Druid连接池初始化数据库连接时长也加长了很多。
下图是测试商品列表接口时，宿主机的性能反映，可以看出消耗最高的两个分别是我们的应用Java进程和查询MySQL进程。
II. JMeter报错问题
这一部分并没有解决，原本想照着视频上启动5000个线程循环10次，但发现，JMeter压测到半途总是报错，请求异常，错误都是网络连接的问题。以下是尝试解决方案，并没有解决问题。
修改操作系统注册表
1、打开注册表：regedit
2、找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters
3、新建 DWORD值，name：TcpTimedWaitDelay，value：30（十进制） ——> 设置为30秒（默认240）
4、新建 DWORD值，name：MaxUserPort，value：65534（十进制） ——> 设置最大连接数65534
5、重启系统就行了
III. 商品超卖问题
商品超卖问题是秒杀系统中除了性能优化，另一个最为关注的问题之一。由于我们的代码在生产环境中面临着超高并发的挑战，考虑业务需求我们也几乎不会对控制层代码进行加锁保证线程安全。所以，不做其他操作的情况下，极有可能发生商品超卖的问题。
秒杀商品和正常下单的逻辑是一致的，一旦确定可以下单了，业务逻辑主要包含两件事：
- 扣减库存 (前提库存程序判断肯定是够的，注意是程序，不代表真的够);
- 创建秒杀订单，或者正常订单，反正是要落地的。
上面两步必须要么全部成功，要么全部失败。很容易想到，我们可以通过事务机制来保证这一原子特性。
「秒杀接口逻辑」
我们实现对应的控制层秒杀接口，可以看到，我们的业务规则首先是判断用户是否登录，然后查看商品的库存是否充足，充足的情况下再判断该用户是否已经成功秒杀过该商品 (每人限秒一个)。上述过程都满足，我们才会去进行秒杀商品，也就是包括减库存和下单两件事。
//SecKillController.java@RequestMapping("/kill")
public String secKill(Model model, User user, @RequestParam("goodsId") Long goodsId) {if (user == null) {return "login";}model.addAttribute("user", user);GoodsVO goods = goodsService.getGoodsDetailById(goodsId); // 《第一处》// 判断库存if (goods.getStockCount() <= 0) {model.addAttribute("errorMsg", CodeMsg.SECKILL_OVER.getMsg());return "kill_fail";}// 判断是否已经秒杀到商品，防止一人多次秒杀成功SecKillOrder order = orderService.getSecKillOrderByUserIdAndGoodsId(user.getId(), goodsId); // 《第二处》if (order != null) {model.addAttribute("errorMsg", CodeMsg.SECKILL_REPEAT.getMsg());return "kill_fail";}// 正常进入秒杀流程：1.减少库存，2.创建订单，3-写入秒杀订单 三步需要原子操作OrderInfo orderInfo = secKillService.secKill(user, goods);// 进入订单详情页model.addAttribute("orderInfo", orderInfo);model.addAttribute("goods", goods);return "order_detail";
}//SecKillService.java/*** 减少库存，下订单，写入秒杀订单* 需要用事务保证原子性* @param user* @param goods* @return*/
@Transactional
public OrderInfo secKill(User user, GoodsVO goods) {// 减少库存goodsService.reduceStock(goods);// 秒杀下单return orderService.createSecKillOrder(user, goods);
}
减少库存的 Service 层和 Dao 层方法如下：
//GoodsService.java/*** 减小库存* @param goods 对goods进行的库存进行更新*/
public int reduceStock(GoodsVO goods) {SecKillGoods g = new SecKillGoods();g.setGoodsId(goods.getId());g.setStockCount(goods.getStockCount() - 1); // 设置库存值return goodsDao.updateStock(g);
}// GoodsDao.java/*** 更新库存* @param g* @return*/
@Update("UPDATE miaosha_goods SET stock_count = #{stockCount} WHERE goods_id = #{goodsId}")
int updateStock(SecKillGoods g);
上面的实现方式在JMeter压测下，果然发生了超卖现象，超卖到下了几千个订单。
原因是什么呢？
我们分析控制层的代码，第一处判断商品库存，多个线程获取到商品库存后可能执行时间片被其他线程抢占，等到别的线程秒杀完，原来的线程并不会更新最新的库存，而是使用的大于0的旧值，也就会继续第二处判断是否包含订单。
同样判断是否有订单，这里对于大多数用户来说确实是没有订单记录的，因为秒杀成功的只有少数人。就算有记录，和第一处一样，同一个用户连续请求两次，第一次判断没有记录，然后线程等待，第二次也判断没有记录，线程也等待，然后第一次的线程继续下单秒杀成功，此时对于第二个线程还是不知道的，会继续下单，重复秒杀。
至于我们扣减库存，下单的逻辑也仅仅只是保证了操作的原子性，并没有保证商品超卖现象不会发生。由于第一步多线程获取秒杀商品的信息不是最新的，这样在 g.setStockCount(goods.getStockCount() - 1); 设置更新库存值时也不是最新的，所以才会出现那么多超卖订单的出现。
初步解决超卖问题：
我们先来解决更新的库存值不是最新的问题，其实我们完全可以利用数据库来解决这个问题，每次来一个下单请求，我们将数据库中的库存减1即可，数据库的悲观锁会保证我们库存数是不断减1的。
/*** 减小库存* @param goods 对goods进行的库存进行更新*/
public int reduceStock(GoodsVO goods) {SecKillGoods g = new SecKillGoods();g.setGoodsId(goods.getId());return goodsDao.updateStock(g);
}/*** 更新库存* @param g* @return*/
@Update("UPDATE miaosha_goods SET stock_count = stock_count - 1 WHERE goods_id = #{goodsId}")
int updateStock(SecKillGoods g);
再次压测，问题仍然存在。
解决库存为负数的问题：
我们已经保证了每次库存的更新是严格按照每次减1的顺序进行更新的，那么还会超卖说明是我们确切的有超过数量的线程数成功经过前面两步的判断放行过来的。那么自然的我们在写多线程程序的时候可能会想到加锁等保证可见性，保证前两步的判断不会出错，但其实我们的最终目标只是不要超卖，保证固定数量的线程数成功即可。所以我们可以在数据库更新库存的时候增加判断条件 stock_count > 0。
/**
*更新库存，解决商品超卖问题的关键所在* @param g* @return*/
@Update("UPDATE miaosha_goods SET stock_count = stock_count - 1 WHERE goods_id = #{goodsId} AND stock_count > 0")
int updateStock(SecKillGoods g);
这样就可以确保我们的库存不会变成负数，利用的是数据库的悲观锁机制。
但是压测时，我们发现，创建的订单数还是超了，这是为什么呢？
我们的减库存、下单代码如下：
/*** 减少库存，下订单，写入秒杀订单* 需要用事务保证原子性，默认传播方式是REQUIRED，没事务创建事务，有事务事务* @param user* @param goods* @return*/
@Transactional
public OrderInfo secKill(User user, GoodsVO goods) {// 减少库存int updateRows = goodsService.reduceStock(goods);logger.info("当前库存为：" + goods.getStockCount() + "，减少库存更新记录数为：" + updateRows);// 秒杀下单return orderService.createSecKillOrder(user, goods);
}
减库存我们用的是数据库保证了数据库层面数据的正确性，但是代码里仍然是存在问题的。我们查看日志信息，可以清晰的发现，后面库存实际为0的时候，goods 对象的库存数还是之前大于0的旧值。其实减少库存的操作已经没有成功，但是我们没有判断，所以继续下单导致超卖。
解决下单超出问题：
解决这个问题仅仅需要保证数据库减库存操作成功，便可以创建订单，否则不创建订单。
// SecKillController.java@RequestMapping("/kill")
public String secKill(Model model, User user, @RequestParam("goodsId") Long goodsId) {if (user == null) {return "login";}model.addAttribute("user", user);GoodsVO goods = goodsService.getGoodsDetailById(goodsId);// 判断库存if (goods.getStockCount() <= 0) {model.addAttribute("errorMsg", CodeMsg.SECKILL_OVER.getMsg());return "kill_fail";}// 判断是否已经秒杀到商品，防止一人多次秒杀成功SecKillOrder order = orderService.getSecKillOrderByUserIdAndGoodsId(user.getId(), goodsId);if (order != null) {model.addAttribute("errorMsg", CodeMsg.SECKILL_REPEAT.getMsg());return "kill_fail";}// 正常进入秒杀流程：1.减少库存，2.创建订单，3-写入秒杀订单 三步需要原子操作OrderInfo orderInfo = secKillService.secKill(user, goods);if (orderInfo != null) {// 进入订单详情页model.addAttribute("orderInfo", orderInfo);model.addAttribute("goods", goods);return "order_detail";} else {model.addAttribute("errorMsg", CodeMsg.SECKILL_OVER.getMsg());return "kill_fail";}
}//GoodsService.java/*** 减少库存，下订单，写入秒杀订单* 需要用事务保证原子性，默认传播方式是REQUIRED，没事务创建事务，有事务事务* @param user* @param goods* @return*/
@Transactional
public OrderInfo secKill(User user, GoodsVO goods) {// 减少库存int updateRows = goodsService.reduceStock(goods);logger.info("当前库存为：" + goods.getStockCount() + "，减少库存更新记录数为：" + updateRows);// 减少库存成功才进行秒杀下单if (updateRows == 1) {return orderService.createSecKillOrder(user, goods);}// 如果库存没有更新成功，则不能进行下单else {return null;}
}
再重新进行压测，便解决商品超卖问题。
问题真的解决了吗？
压测时，我们缩减为3个用户多次请求进行抢购。我们可以看到用户重复秒杀同一商品的情形。为什么出现呢，我们之前已经分析过了，判断用户是否已经秒杀到商品是线程不安全的，而等到后面进行秒杀下单时也没有再进行判断。
如果判断用户是否重复秒杀呢，其实我们可以给用户与商品添加上一个组合唯一索引，这样重复创建订单就会插入纪录失败，这样由于事务的存在，库存减少也会回滚。
解决重复秒杀问题：
create index userid_goodsid_unique_index on miaosha_order(user_id, goods_id);
再次压测结果：
这次我们看到订单记录也是没有问题的。
IV. 秒杀接口优化
上面实现商品不超卖的方案是从数据库悲观锁层面保证的，每一次秒杀请求都会进行数据库的访问，这其实在秒杀场景下是扛不住访问压力的。我们可以采用Redis预减库存+MQ异步下单+接口限流的方案提高系统的性能，缓和瞬时请求量庞大的问题。
首先访问内存标记，是否已经秒杀结束。然后通过Redis预减库存的方式放行库存数量的请求通过，接下来再采取之前的方式通过数据库保证不超卖。
// SecKillController.java@Autowired
private MQSender mqSender;
@Autowired
private RedisTemplate<String, Object> redisTemplate;/*** 内存标记Map，key为商品id，value为是否秒杀结束，用于减少对Redis的访问* 该内存标记非线程安全，但不会影响功能，只是有多个线程多次复写某商品卖完*/
private HashMap<Long, Boolean> goodsSecKillOverMap = new HashMap<>();@RequestMapping("/asynckill")
public String asyncSecKill(Model model, User user, @RequestParam("goodsId") Long goodsId) {if (user == null) {return "login";}model.addAttribute("user", user);// 先访问内存标记，查看是否卖完if (goodsSecKillOverMap.containsKey(goodsId) && goodsSecKillOverMap.get(goodsId)) {model.addAttribute("errorMsg", CodeMsg.SECKILL_OVER.getMsg());return "kill_fail";}// Redis预减库存Long nowStock = redisTemplate.opsForValue().decrement(GoodsKey.goodsStockKey.getPrefix() + ":" + goodsId);logger.info("商品" + goodsId + "预减库存完Redis当前库存数量为：" + nowStock);// 如果库存预减完毕，则直接返回秒杀失败if (nowStock < 0) {// 记录当前商品秒杀完毕goodsSecKillOverMap.put(goodsId, true);model.addAttribute("errorMsg", CodeMsg.SECKILL_OVER.getMsg());return "kill_fail";}// 判断是否已经秒杀到商品，防止一人多次秒杀成功SecKillOrder order = orderService.getSecKillOrderByUserIdAndGoodsId(user.getId(), goodsId);if (order != null) {model.addAttribute("errorMsg", CodeMsg.SECKILL_REPEAT.getMsg());return "kill_fail";}// 正常进入秒杀流程：入队进行异步下单mqSender.sendSecKillMessage(new SecKillMessage(user, goodsId));model.addAttribute("killMsg", CodeMsg.SECKILL_WAITTING.getMsg());return "kill_wait";
}
「异步下单」
下单的时候这里仅仅是通过发送一个下单请求消息进入队列，然后立即返回排队中的结果给用户。异步下单的方式，将系统的瞬时请求进行削峰。
//MQSender.java/*** 发送秒杀请求消息，包含用户和商品id* @param secKillMessage*/
public void sendSecKillMessage(SecKillMessage secKillMessage) {logger.info("用户" + secKillMessage.getUser().getId() + "发起秒杀" + secKillMessage.getGoodsId() + "商品请求");rabbitTemplate.convertAndSend(RabbitMQConfig.QUEUE, secKillMessage);
}//MQReceiver.java
@RabbitHandler
public void receiveSecKillMessage(@Payload SecKillMessage secKillMessage) {User user = secKillMessage.getUser();Long goodsId = secKillMessage.getGoodsId();logger.info("收到用户" + user.getId() + "秒杀" + goodsId + "商品请求");// 判断库存GoodsVO goods = goodsService.getGoodsDetailById(goodsId);if (goods.getStockCount() <= 0) {return;}// 判断是否已经秒杀到商品，防止一人多次秒杀成功SecKillOrder order = orderService.getSecKillOrderByUserIdAndGoodsId(user.getId(), goodsId);if (order != null) {return;}// 正常进入秒杀流程：1.减少库存，2.创建订单，3-写入秒杀订单 三步需要原子操作OrderInfo orderInfo = secKillService.secKill(user, goods);if (orderInfo != null) {// 秒杀成功} else {// 秒杀失败}
}
利用JMeter压测时打印的日志如下：
INFO 70092 --- [o-8080-exec-124] SecKillController : 商品2预减库存完Redis当前库存数量为：5
INFO 70092 --- [o-8080-exec-168] SecKillController : 商品2预减库存完Redis当前库存数量为：6
INFO 70092 --- [nio-8080-exec-2] SecKillController : 商品2预减库存完Redis当前库存数量为：4
INFO 70092 --- [o-8080-exec-194] SecKillController : 商品2预减库存完Redis当前库存数量为：3
INFO 70092 --- [io-8080-exec-76] SecKillController : 商品2预减库存完Redis当前库存数量为：2
INFO 70092 --- [o-8080-exec-130] SecKillController : 商品2预减库存完Redis当前库存数量为：1
INFO 70092 --- [o-8080-exec-138] SecKillController : 商品2预减库存完Redis当前库存数量为：0
INFO 70092 --- [io-8080-exec-26] SecKillController : 商品2预减库存完Redis当前库存数量为：-1
INFO 70092 --- [io-8080-exec-79] SecKillController : 商品2预减库存完Redis当前库存数量为：-2
INFO 70092 --- [io-8080-exec-14] SecKillController : 商品2预减库存完Redis当前库存数量为：-3
INFO 70092 --- [o-8080-exec-201] SecKillController : 商品2预减库存完Redis当前库存数量为：-4
INFO 70092 --- [o-8080-exec-204] SecKillController : 商品2预减库存完Redis当前库存数量为：-5
INFO 70092 --- [o-8080-exec-202] SecKillController : 商品2预减库存完Redis当前库存数量为：-6
INFO 70092 --- [o-8080-exec-205] SecKillController : 商品2预减库存完Redis当前库存数量为：-7
INFO 70092 --- [o-8080-exec-206] SecKillController : 商品2预减库存完Redis当前库存数量为：-8
INFO 70092 --- [o-8080-exec-221] SecKillController : 商品2预减库存完Redis当前库存数量为：-9
INFO 70092 --- [o-8080-exec-225] SecKillController : 商品2预减库存完Redis当前库存数量为：-10
INFO 70092 --- [o-8080-exec-211] SecKillController : 商品2预减库存完Redis当前库存数量为：-11
INFO 70092 --- [o-8080-exec-224] SecKillController : 商品2预减库存完Redis当前库存数量为：-12
INFO 70092 --- [o-8080-exec-220] SecKillController : 商品2预减库存完Redis当前库存数量为：-14
INFO 70092 --- [o-8080-exec-208] SecKillController : 商品2预减库存完Redis当前库存数量为：-13
INFO 70092 --- [o-8080-exec-207] SecKillController : 商品2预减库存完Redis当前库存数量为：-15
INFO 70092 --- [o-8080-exec-218] SecKillController : 商品2预减库存完Redis当前库存数量为：-16
INFO 70092 --- [o-8080-exec-222] SecKillController : 商品2预减库存完Redis当前库存数量为：-17
INFO 70092 --- [o-8080-exec-219] SecKillController : 商品2预减库存完Redis当前库存数量为：-18
INFO 70092 --- [o-8080-exec-223] SecKillController : 商品2预减库存完Redis当前库存数量为：-19
INFO 70092 --- [o-8080-exec-216] SecKillController : 商品2预减库存完Redis当前库存数量为：-20
INFO 70092 --- [o-8080-exec-217] SecKillController : 商品2预减库存完Redis当前库存数量为：-21
INFO 70092 --- [o-8080-exec-213] SecKillController : 商品2预减库存完Redis当前库存数量为：-22
INFO 70092 --- [o-8080-exec-215] SecKillController : 商品2预减库存完Redis当前库存数量为：-23
INFO 70092 --- [o-8080-exec-212] SecKillController : 商品2预减库存完Redis当前库存数量为：-24
INFO 70092 --- [o-8080-exec-214] SecKillController : 商品2预减库存完Redis当前库存数量为：-25
INFO 70092 --- [o-8080-exec-203] SecKillController : 商品2预减库存完Redis当前库存数量为：-26
INFO 70092 --- [o-8080-exec-210] SecKillController : 商品2预减库存完Redis当前库存数量为：-27
INFO 70092 --- [o-8080-exec-209] SecKillController : 商品2预减库存完Redis当前库存数量为：-28
INFO 70092 --- [o-8080-exec-124] MQSender : 用户13000000004发起秒杀2商品请求
INFO 70092 --- [o-8080-exec-168] MQSender : 用户13000000001发起秒杀2商品请求
INFO 70092 --- [nio-8080-exec-2] MQSender : 用户13000000000发起秒杀2商品请求
INFO 70092 --- [o-8080-exec-194] MQSender : 用户13000000006发起秒杀2商品请求
INFO 70092 --- [o-8080-exec-130] MQSender : 用户13000000005发起秒杀2商品请求
INFO 70092 --- [o-8080-exec-138] MQSender : 用户13000000003发起秒杀2商品请求
INFO 70092 --- [io-8080-exec-76] MQSender : 用户13000000002发起秒杀2商品请求
INFO 70092 --- [cTaskExecutor-1] MQReceiver : 收到用户13000000002秒杀2商品请求
INFO 70092 --- [cTaskExecutor-1] SecKillService : 当前库存为：7，减少库存更新记录数为：1
INFO 70092 --- [cTaskExecutor-1] MQReceiver : 收到用户13000000005秒杀2商品请求
INFO 70092 --- [cTaskExecutor-1] SecKillService : 当前库存为：6，减少库存更新记录数为：1
INFO 70092 --- [cTaskExecutor-1] MQReceiver : 收到用户13000000003秒杀2商品请求
INFO 70092 --- [cTaskExecutor-1] SecKillService : 当前库存为：5，减少库存更新记录数为：1
INFO 70092 --- [cTaskExecutor-1] MQReceiver : 收到用户13000000004秒杀2商品请求
INFO 70092 --- [cTaskExecutor-1] SecKillService : 当前库存为：4，减少库存更新记录数为：1
INFO 70092 --- [cTaskExecutor-1] MQReceiver : 收到用户13000000001秒杀2商品请求
INFO 70092 --- [cTaskExecutor-1] SecKillService : 当前库存为：3，减少库存更新记录数为：1
INFO 70092 --- [cTaskExecutor-1] MQReceiver : 收到用户13000000006秒杀2商品请求
INFO 70092 --- [cTaskExecutor-1] SecKillService : 当前库存为：2，减少库存更新记录数为：1
INFO 70092 --- [cTaskExecutor-1] MQReceiver : 收到用户13000000000秒杀2商品请求
INFO 70092 --- [cTaskExecutor-1] SecKillService : 当前库存为：1，减少库存更新记录数为：1
「接口限流」
通过自定义注解+Spring方法拦截器+Redis访问次数统计的方式，可以对需要限流访问的接口进行限流。
自定义接口 @AccessLimit：
/*** @description: 请求限流注解* @author: guoping wang* @email: Kingdompin@163.com* @date: 2019/5/10 2:11 PM* @project: seckill*/
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Target(ElementType.METHOD)
public @interface AccessLimit {/*** 指定时间* @return*/int seconds() default 60;/*** seconds时间内最多允许访问maxValue次数* @return*/int maxValue();/*** 该请求是否需要登录* @return*/boolean needLogin() default true;
}
Spring拦截器对 @AccessLimit 的处理：
/*** @description: 自定义限流拦截器* @author: guoping wang* @email: Kingdompin@163.com* @date: 2019/5/10 2:16 PM* @project: seckill*/
@Component
public class AccessInterceptor extends HandlerInterceptorAdapter {@Autowiredprivate UserService userService;@Autowiredprivate RedisTemplate<String, Object> redisTemplate;/*** 方法执行前，对方法进行拦截查看是否包含@AccessLimit注解，并进行相应的设置* @param request* @param response* @param handler* @return* @throws Exception*/@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {if (handler instanceof HandlerMethod) {// 获取用户并保存到ThreadLocal中User user = getUser(request);UserContext.setUser(user);HandlerMethod handlerMethod = (HandlerMethod) handler;// 获取方法上@AccessLimit的注解AccessLimit accessLimit = handlerMethod.getMethodAnnotation(AccessLimit.class);if (accessLimit == null) {return true;}// 存在@AccessLimit注解，则需要对注解配置进行获取并进行处理int maxValue = accessLimit.maxValue();int seconds = accessLimit.seconds();boolean needLogin = accessLimit.needLogin();String key = request.getRequestURI();if (needLogin && UserContext.getUser() == null) {render(response, CodeMsg.SESSION_ERROR);return false;}// 不需要登录则根据是否包含user来拼接keykey += "_" + (UserContext.getUser() != null ? user.getId() : "");// 利用Redis实现限流AccessLimitKey accessLimitKey = AccessLimitKey.getAccessKeyWithExpire(seconds);String accessKey = accessLimitKey.getPrefix() + ":" + key;Integer count = (Integer) redisTemplate.opsForValue().get(accessKey);if (count == null) {redisTemplate.opsForValue().set(accessKey, 1);redisTemplate.expire(accessKey, accessLimitKey.expireSeconds(), TimeUnit.SECONDS);}// 仍然在限制内else if (count <= maxValue) {redisTemplate.opsForValue().increment(accessKey);}// 超出最大访问次数限制else {render(response, CodeMsg.ACCESS_BEYOND_LIMIT);return false;}}return true;}/*** 返回页面，被拦截器拦截需要登录却没有登录* @param response* @param codeMsg*/private void render(HttpServletResponse response, CodeMsg codeMsg) throws IOException {response.setContentType("application/json;charset=UTF-8");OutputStream outputStream = response.getOutputStream();String out = JSON.toJSONString(ServerResponse.error(codeMsg));outputStream.write(out.getBytes("UTF-8"));outputStream.flush();outputStream.close();}public User getUser(HttpServletRequest request) {String paramToken = request.getParameter(UserService.COOKIE_TOKEN_NAME);String cookieToken = getCookieValue(request, UserService.COOKIE_TOKEN_NAME);if (StringUtils.isEmpty(cookieToken) && StringUtils.isEmpty(paramToken)) {return null;}// 优先从参数中获取用户tokenString token = StringUtils.isEmpty(paramToken) ? cookieToken : paramToken;// 根据Token查询Userreturn userService.getUserByToken(token);}/*** 根据Cookie的名称获取对应的值* @param request* @param name* @return*/private String getCookieValue(HttpServletRequest request, String name) {Cookie[] cookies = request.getCookies();// 压测下发现问题，cookies可能为空if (cookies != null) {for (Cookie cookie : cookies) {if (cookie.getName().equals(name)) {return cookie.getValue();}}}return null;}
}
