##>>> 我们解决我们重复下单的问题
我们可以使用mysql 的唯一索引 ,在我们的数据库层面保证不能重复下单 我可以控制是唯一的
同一个用户 针对于同一个商品只可以买一个
重复下单 优化
我们
>1.使用数据库唯一索引 一旦是 2个请求 因为mysql 有行级锁你后面的插入的话 其实就会报错
>2. 我们下订单成功后 我就会吧当前用户存入redis中,后面的请求 我就不会访问db
首先 第一 我们的秒杀列表以及秒杀详情 我们从redis缓存中查询了,我们也解决了重复下单的问题
以及超卖的问题 我们此时再基于jmeter查看我们的qps,
我们秒杀时候 浏览器--->controller--->servcice--->db
针对于一个秒杀商品比如说有5000的qps,有10个请求到达service(我们通过redis 的incr)
如果秒杀商品多的话,比如说 你一个场次的商品更多 请求会更多
##>
同一个时间太多请求过来了 我们此时要做一个流量 的削峰
我们使用mq 来对我们的请求的异步处理.我们异步下单
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/b37ea5824bad48d985cf4225821973f9.png)
我们可以做集群处理 我们可以海量接受请求 不至于单个被打崩了
我们应用程序发送消息后 消息是异步的 不知道消息的执行结果
##>
如何通知我们浏览器 的执行结果呢##>>>>>>>>>>
因为我们是bs 架构 是浏览器和服务器 服务器无法主动给浏览器推送消息的
浏览器要想获取服务器的响应信息,必须要发送http请求
##>>>>
我浏览器 它有一个定时器,周期性的执行我们的函数,比如说0.5s执行一次
我们可以采用mq 来实现 针对于一个商品有50个 请求, 有很多秒杀商品同时参与
一个秒杀商品我们放10个请求去操作我们的db, 呢么针对于同一个10点场次的秒杀商品 同时抢购的话
最终就会把我们的db打崩溃了
我们此时就需要做流量的削峰 我们会使用mq对我们的请求进行异步处理
我们可以在服务端做集群,去消费mq的消息
我们也可以在客户端做集群,都往mq 中发消息
我们使用mq来异步处理我们的下单请求,
异步下单之后我们要解决一些问题
1>contreooler---->servie---->dao===>数据库,
我们也仅仅吧我们的消息发送到mq了,但是我们并不知道我们消息的执行结果,
我怎么通知我用户的执行结果呢
因为我们是bs架构,只能浏览器发送数据到服务器。 服务器无法主动给浏览器推送消息的
我们有什么方案 让用户知道我们的下单结果
> 浏览器有定时功能 每隔0.5s 发个请求获取用户的订单结果
我们可以通过定时任务来循环获取这样的结果 但是 存在的问题就是 循环几次
时间多长一些呢
还有就是长连接的场景, 通过websocket 实现 服务器的推送
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/95bfacb0942448e586ef02f70de10e9c.png)
我们浏览器和服务器建立一个长连接 当你服务器有消息后会主动进行推送
我们可以使用websocket技术 来实现可以主动推送的效果
浏览器和websocket建了一个长连接
如果采用ajax 轮询的话,前面是你每隔一段时间发送请求 来建立连接 断开连接 来查询发送请求
这里只是 我建立一次连接就可以了
我们websocket技术来实现推送的功能
1.发起秒杀的请求提示进入队列中的队列中存放phone信息),等待消息
2和websocket服务器建立长连接(把phone作为参数传递到websocket服务器)
3.websocket服务器需要进护客户的映射关系
4.消息给应用胺务器消费,可以获取到. phone和业务执行结果
5.调用websocket接口,根据传过来的phone找到映射关系拿到客户端的长连接引用6.通过这个长连接引用,给有户箦发送消息
4.消息给应用胺务器消费,可以获取到. phone和业务执行结果
5.调用websocket接口,根据传过来的phone找到映射关系拿到客户端的长连接引用6.通过这个长连接引用,给有户箦发送消息
我们异步下单 我们是不知道结果的 我们要吧处理结果告诉浏览器
>1.我们通过定时器 我们可以轮询不断的发送请求 来获取结果
>2.一种我们使用websocket做长连接 有消息就会主动推送给客户端
websocket 只是一个服务器 可以建立长连接
我们可以实现类似于推送的效果
服务器可以主动发消息给浏览器
1.定时上架的功能
>zk 只能让一个节点来执行
>2. 我们使用xxjob 进行分片处理
我们做了缓存预热的设设置
将我们的秒杀列表以及秒杀详情 从redis中查询 提高了qps 并发
2>我们解决了超卖问题
我们基于乐观锁 加版本号的问题解决了超卖的问题
但是大量请求进行update的时候 并不能修改库存,然而数据库的压力还是很大
3. 我们使用redis 的incr ,做缓存的预热扣减 目的减少进入数据库的人数
if(remainCount<0){
## throw
}
4. 重复下单问题 我们使用数据库的唯一索引解决重复下单问题,在数据库中建立唯一索引
2. 当秒杀抢购商品成功后 会将用户的user 存入redis中 用redis的set来判断当前用户的iphone 是不是抢购国
5. 分析异步下单情况 一个商品落入service 有10个,但是同一场次有很多个商品,就会有50*10的请求同时落入到数据库中, 数据库压力会变大
--使用mq进行异步处理
同时我们也可以将客户端和服务端做集群 来提高我们系统的处理能力
我们客户端是不知道你处理成功还是没有成功的
>q1 使用ajax 轮询来查询
>q2 我们可以使用websocket建立长连接
我们会通过mq 吧消息异步发送给我们的 应用service
我们异步消费的结果不知道怎么相应给我们客户端
我们可以使用webSocket 浏览器和服务器之间的长连接 实现浏览器和长连接的建立连接 实现消息推送
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/f6d03b41d7764d65aa33e091a4d99b41.png)
我们要在websocket服务端建立会话关系,websocket 服务端 有一个map集合 针对于我们的内容进行存储
建立连接之后 我们就可以通过websocket给客户端A 和客户端B 发送这样的消息
在map中寻找映射关系 然后再找到对应的session对象 进行通知到我们客户端
我们会吧消息异步发送给应用服务器,然后我们就会遇到问题,我们应用服务器不知道怎么通知到浏览器
>我们可以采用ajax 负责轮询
>我们可以采用websocket 相当于我浏览器和服务器之间可以建立长连接,我们可以实现浏览器和服务器建立连接之后怎么实现消息推送
我们bs结构服务端是没有办法主动发消息给客户端的,我们可以发请求响应
或者 建立一个长连接
我们基于这种方式实现了类似于服务端主动推送
应对很多websocket连接 如何处理 单台机器很多websocket连接 对服务器的要求就会变大,
我们可以在websocket 做集群,用ngixn 做转发 我们通过nginx 吧请求进行分发给websocket,基于hash进行分发
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/9dcee62d3b2b47f8a48e35067924cfaf.png)
我们可以通过ngixn加集群的方式 来增加我们的能力, 应用程序端通过mq进行通知
找到就可以通知 找不到就不用通知了
Q2 我们客户端和服务器建立连接之后 如果没有主动关闭我们的窗口(连接一直存在)
我们建立好通道后 不发消息 连接会一直存在
我们可以采用客户端心跳的方式,发送心跳机制,来判断你客户端是否还存活
我要有心跳机制来检测你那些机器下线了,下线了就给他剔除了,类似于我们注册中心
付费的服务 我们可以采用付费的平台 goEasy
我们把应用改成了异步下单的这种方式, 我们要把下单改成异步mq下单,封装mq消息进行分发
我们改成了异步下单,我们之前相当于5000个请求打到服务端来,我们的目的是为了减少请求直接打到我们的
service,使用mq进行缓冲请求,
如果消费速度很慢的话我们可以设置集群
/
我们可以将秒杀成功或者秒杀失败的消息放入到mq 打个标签
10个库存 我多点了1个 只卖了9个
这就是我们成功或者失败我们都要发送消息的
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/40b7bcbb18bb4d868861faa5e678f072.png)
p120
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/db1cd47a70724d21b3685c78ff7dca2b.png)
springboot整合websocket,当我们建立连接之后把映射关系维护,map是县城不安全的
我们都操作同一个map的话,会出现线程不安全的问题,所以我们会用conneHashMap
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/e2745055a65d41d18c187fb4f9148c2b.png)
我们通过事件的方式帮我们响应
我们找到我们的token来继续session发送消息
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/dcf8252d4e694fd08a30df3ed902ea29.png)
我们通过token就可以找到会话对象,然后把消息发送过去
我们可以通过websocket实现服务器向浏览器的主动推送
我们bs结构服务端是没有办法主动发消息给客户端的,我们可以发请求响应
或者 建立一个长连接
我们基于这种方式实现了类似于服务端主动推送
q1 应对很多websocket连接,我们该如何处理,单台机器很多websocket连接,对服务器的性能要求就很高
我们可以在websocket做集群,用nginx做转发, 我们通过nginx把请求进行分发给websocket,基于hash进行分发
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/588e42152f4f473292b83ef920d0cb9d.png)
我们可以通过ngixn加集群的方式 来增加我们的能力,
应用程序端通过mq进行通知找到就可以通知 找不到就不用通知了
我们客户端和服务器建立连接之后 如果没有主动关闭我们的窗口(连接一直存在)
我们建立好通道后 不发消息 连接会一直存在
1>我们定时给客户端发送心跳包 心跳机制 我服务端怎么知道客户端是否还健康
我们可以采用心跳机制来判断 客户端是否还存在
我要有心跳机制来检测那些机器下线了 下线就可以剔除掉
类似于我们的注册中心
付费的服务 我们可以采用付费的平台 goEasy
这样我们的流程就改成了异步下单的流程了,我们之前是相当于5000个服务同时打过来
我们的目的是为了减少请求,直接打到service和直接打到数据库中
我们使用Mq作为流量的缓冲, 对于消费过慢的的话我们可以采用集群的方式
我们可以将秒杀成功或者秒杀失败的消息放入到mq 打个标签
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/4cd1198c4fc24fdd83670e4805752b71.png)
同时我们需要监听失败还有超时取消的mq 因为我们失败之后我们需要将redis缓存进行加1 处理
我最终把消息推送给前端 异步下单后我们怎么排查我们的错误
预库存回补 我要做库存回补 因为我此时要做预库存回补
当我们成功后 我们会发延迟消息 当我们成功后如果没有支付我们会
## 支付超时的订单
过了10分钟还没有支付,我们要取消我们的订单 做库存回补
orderInfo.canalOrder() 根据订单编号判断是否有没有超时
超时我们就取消订单
###############>>>>>>>>>>>>>>>>>
我们秒杀的逻辑 异步下单 我们是否要进行压测 我们加入mq 的目的是为了缓解并发的压力
异步下单的逻辑 比如说我们使用mq redis 延时队列 tag 的过滤监听 websocket 的通知
>>>>>>>>.订单下单完毕后 我们要进行支付
我们可以依靠与支付宝的SDK 来做支付 依托于支付宝的沙箱环境
1.Q1 网站支付的流程 2.内网穿透
2,事务 spring是怎么感知我们的事物的 或者分布式事务
支付逻辑
订单下达完毕后我们要做支付
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/41e19b1351f6480bb3fe30bf51f97ef5.png)
我们的参数可能被别人拦截请求并且篡改 参数 我们要把我们的数据进行加密操作
支付宝采用的是非对称加密,加密分为对称加密和非对称加密
md5是单项的
我们可以使用公钥加密 私钥解密 或者我们可以使用私钥加密 公钥解密
#>对于支付宝来说 是私钥加密 公钥给别人 进行解密
要能实现回调 你的应用程序必须在互联网上是可见的
我们可以使用netApp做内网穿透
为什么我们的应用服务器是要求公网可见
因为此时支付成功后 支付宝会异步发请求发给我们的url
##>>
我们要实现接口的幂等性 就是执行多次 实际上只有1次
# 同一个订单 无论执行多少次 实际上只能执行一次
## 我们怎么实现幂等性 支付表 或者支付流水表 使用orderNo 作为唯一主键
我们要保证我们的幂等性
在我们异步回调时候 如果我们没有收到支付宝的回调消息
我们要定位 为什么没有回调成功 可能是网络原因
此时我我们要提供一个接口 出现这种异常情况下 我们要进行人工补单
我们要在秒杀中做支付 此时我们还是服务的分离
前端--->秒杀--->支付--->支付宝
我们完成统一支付功能
我们把appid 配置在nacos上 (配置 私钥 公钥)
每个服务要传递自己的同步地址和异步,地址.因为在秒杀会处理我支付完毕的逻辑
会员服务会处理我们会员充值完毕之后的逻辑
同样我们基于feign发起的调用,同样我们如果调用失败了 我们要有PayFeignApi做回调
我们要搞清楚它的支付流程 以及理解它的支付逻辑
比如说支付中的交易参数 我们平台的敏感数据是怎么做的
我们使用的非堆成加密 私钥加密 公钥解密