# Table of Contents
- [架构](#架构)
- [秒杀业务分析](#秒杀业务分析)
- [业务特点](#业务特点)
- [性能瓶颈](#性能瓶颈)
- [数据库锁竞争](#数据库锁竞争)
- [秒杀读多写少的特性](#秒杀读多写少的特性)
- [技术难点](#技术难点)
- [秒杀流程](#秒杀流程)
- [数据库表设计](#数据库表设计)
- [重要基础功能开发](#重要基础功能开发)
- [result结果集封装](#result结果集封装)
- [redis通用缓存Key封装](#redis通用缓存key封装)
- [明文密码两次MD5处理](#明文密码两次md5处理)
- [第一次的目的](#第一次的目的)
- [第二次的目的](#第二次的目的)
- [全局异常处理器](#全局异常处理器)
- [异常抛出的流程](#异常抛出的流程)
- [全局异常处理器处理思路：](#全局异常处理器处理思路)
- [实现](#实现)
- [分布式Session--SSO系统](#分布式session--sso系统)
- [秒杀系统优化](#秒杀系统优化)
- [高并发-访问拦截](#高并发-访问拦截)
- [动静分离与反向代理层访问拦截](#动静分离与反向代理层访问拦截)
- [Web层和Service层访问拦截](#web层和service层访问拦截)
- [高并发-分流](#高并发-分流)
- [高并发-限流](#高并发-限流)
- [计数器--redis预减库存](#计数器--redis预减库存)
- [异步化--消息队列](#异步化--消息队列)
- [数学公式验证码](#数学公式验证码)
- [正确性-超卖问题](#正确性-超卖问题)
- [原因](#原因)
- [解决重复下单](#解决重复下单)
- [防作弊--安全性](#防作弊--安全性)
- [秒杀接口地址隐藏](#秒杀接口地址隐藏)
- [限流](#限流)
- [其它优化](#其它优化)
- [先下单再减库存](#先下单再减库存)
- [网站设计概述](#网站设计概述)
- [参考资料](#参考资料)
# 架构
# 秒杀业务分析
1. 正常电子商务流程（1）查询商品；（2）创建订单；（3）扣减库存；（4）更新订单；（5）付款；（6）卖家发货
2. 秒杀业务的特性（1）低廉价格；（2）大幅推广；（3）瞬时售空；（4）一般是定时上架；（5）时间短、瞬时并发量高；
## 业务特点
## 性能瓶颈
### 数据库
[数据库性能对比](https://cloud.tencent.com/developer/article/1005399)
I： 首先MySQL自身对于高并发的处理性能就会出现问题，一般来说，**MySQL的处理性能会随着并发thread上升而上升，但是到了一定的并发度之后会出现明显的拐点**，之后一路下降，最终甚至会比单thread的性能还要差。
II： 其次，超卖的根结在于**减库存操作是一个事务操作**，需要先select，然后insert，最后update -1。最后这个-1操作
是不能出现负数的，但是当多用户在有库存的情况下并发操作，出现负数这是无法避免的。
III：最后，当减库存和高并发碰到一起的时候，由于操作的库存数目在同一行，就会出现争抢**InnoDB行锁**的问题，导致出现互相等待甚至死锁，从而大大降低MySQL的处理性能，最终导致前端页面出现超时异常。
- Mysql执行单条的SQL语句其实是非常快的
- 主要是**行级锁事务的等待**，网络的延迟和GC回收！
update number set x=x-1 where (x -1 ) >= 0;
这个语句在innodb，设置了事务和RR可重复读隔离级别下，并且使用到了索引，是会加上行锁（X锁）的，可以直接解决超卖问题，但是高并发扛不住，行锁竞争严重。所以使用消息队列，做一个缓冲，减轻mysql行锁竞争的压力。
消息队列的作用：1. 减轻mysql行锁的竞争 2. 异步下单
### 秒杀读多写少的特性
使用缓存
## 技术难点
秒杀系统主要解决三大问题：
一、**瞬时的高并发访问**。抢购和普通的电商销售有所不同，普通的电商销售，流量是比较平均的，虽然有波峰波谷，但不会特别突出。而抢购是在特定时间点进行的推销活动，抢购开始前，用户不断刷新页面，以获得购买按钮；抢购开始的一瞬间，集中并发购买。
二、**数据正确性**。抢购毕竟是一种购买行为，需要购买、扣减库存、支付等复杂的流程，在此过程中，要保证数据的正确性，防止**超卖（卖出量超过库存）**的发生。
三、**防作弊**。无论是火车票的购买，还是低价商品的促销，肯定不希望某些客户买到所有的商品，应尽量保证公平性。通过购票插件购买火车票，阿里巴巴抢月饼事件等，需要限制技术性用户绕过网站的限制，通过技术手段获得不良收益。
解决高并发的问题，主要有如下的三个思路：**访问拦截，分流，限流**。
主流的Web站点采用分层的架构设计，如果你的应用还没有采用分层的架构，那么先做分层设计吧。一般来说，浏览器采用了html/js/css技术，负责数据的展示；反向代理一般采用nginx，负责负载均衡；Web层是指Php，Tomcat等应用服务器，负责用户状态的维护，http协议处理等；service层一般是rpc调用，当然也有用http的，例如spring cloud；数据库存储一般是mongodb，mysql等持久化数据方案。用户的一次数据访问，例如查询商品库存，数据是从上层依次调用到DB，逐层返回数据。
## 秒杀流程
登录
准备进入秒杀
**开始秒杀**
整体流程
## 数据库表设计
商品表 秒杀商品表
订单表 秒杀订单表
如果直接在商品表里面添加一个字段表明是否是秒杀商品，会让商品表难以维护
# 重要基础功能开发
## result结果集封装
暴露接口，而不是直接去创建对象，面向接口编程，进行解耦合
由于错误有多种原因，所以使用CodeMsg封装code，msg
```java
return Result.success("hello");
return new Result<String>(50010,"success","hello"); //耦合度太高，硬编码
```
```java
public class Result<T> {
private int code;
private String msg;
private T data;
//construtor
public static <T> Result<T> success(T data) {
return new Result<T>(data);
}
public static <T> Result<T> error(CodeMsg cm) {
return new Result<T>(cm);
}
//get-set
}
```
```java
public class CodeMsg {
private int code;
private String msg;
//construtor
public static CodeMsg SUCCESS=new CodeMsg(0,"success");
public static CodeMsg SERVER_ERROR=new CodeMsg(500100,"服务端异常");
//get-set
}
```
## redis通用缓存Key封装
[电商系统，Redis做缓存时===>通用缓存key的封装](https://blog.csdn.net/tiankong_12345/article/details/86651613)
采用**字符串**的数据类型，但是不同模块的key可能会相互影响，所以应该设计这样的key "UserKey:id1"，"OrderKey:id1"
**模板模式：接口+抽象类+具体实现**
**优点**
具体细节步骤实现定义在子类中，子类定义详细处理算法是不会改变算法整体结构
**代码复用**的基本技术，在数据库设计中尤为重要
存在一种反向的控制结构，通过一个父类调用其子类的操作，通过子类对父类进行扩展增加新的行为，符合“**开闭原则**”
**缺点**
每个不同的实现都需要定义一个子类，会导致类的个数增加，系统更加庞大
接口
```java
public interface KeyPrefix {
public int expireSeconds() ;
public String getPrefix() ;
}
```
**抽象类**
```java
public abstract class BasePrefix implements KeyPrefix{
private int expireSeconds;
private
springboot+redis实现秒杀系统.zip （269个子文件） 
MiaoshaController.class 9KB MiaoshaService.class 7KB RedisService.class 7KB GoodsController.class 6KB UserUtil.class 5KB AccessInterceptor.class 5KB MQConfig.class 4KB DemoController.class 4KB MiaoshaUserService.class 4KB OrderService.class 3KB UserArgumentResolver.class 3KB MQReceiver.class 3KB CodeMsg.class 3KB OrderInfo.class 3KB OrderController.class 3KB GlobalExceptionHandler.class 2KB LoginController.class 2KB Result.class 2KB MiaoshaUser.class 2KB GoodsService.class 2KB RedisConfig.class 2KB Goods.class 2KB Md5Util.class 2KB MQSender.class 2KB OrderDao.class 2KB DBUtil.class 2KB IsMobileValidator.class 2KB MiaoshaGoods.class 1KB RedisPoolFactory.class 1KB GoodsDetailVo.class 1KB GoodsVo.class 1KB ValidatorUtil.class 1KB GoodsDao.class 1KB LoginVo.class 1KB BasePrefix.class 1KB MiaoshaOrder.class 1KB WebConfig.class 1KB UserContext.class 958B IsMobile.class 937B OrderDetailVo.class 910B UserService.class 893B MiaoshaMessage.class 844B User.class 799B MainApplication.class 708B MiaoshaUserDao.class 680B MiaoshaKey.class 670B GoodsKey.class 664B MiaoshaUserKey.class 653B GlobalException.class 636B UUIDUtil.class 598B AccessKey.class 555B UserKey.class 551B UserDao.class 535B OrderKey.class 516B AccessLimit.class 504B KeyPrefix.class 197B .classpath 1KB bootstrap.css 143KB bootstrap.css 143KB bootstrap.min.css 118KB bootstrap.min.css 118KB bootstrap-theme.css 26KB bootstrap-theme.css 26KB bootstrap-theme.min.css 23KB bootstrap-theme.min.css 23KB layer.css 14KB layer.css 14KB layer.css 5KB layer.css 5KB glyphicons-halflings-regular.eot 20KB glyphicons-halflings-regular.eot 20KB
loading-0.gif 6KB loading-0.gif 6KB loading-2.gif 2KB loading-2.gif 2KB loading-1.gif 701B loading-1.gif 701B goods_detail.htm 7KB goods_detail.htm 7KB order_detail.htm 3KB order_detail.htm 3KB
goods_detail.html 3KB goods_detail.html 3KB login.html 3KB login.html 3KB order_detail.html 2KB order_detail.html 2KB goods_list.html 2KB goods_list.html 2KB miaosha_fail.html 246B miaosha_fail.html 246B hello.html 232B hello.html 232B MiaoshaController.java 7KB GoodsController.java 5KB MiaoshaService.java 5KB RedisService.java 5KB UserUtil.java 3KB AccessInterceptor.java 3KB MiaoshaUserService.java 3KB共 269 条
- 1
- 2
- 3
资源评论
