java高并发实战＜2＞

##>>>  我们解决我们重复下单的问题
我们可以使用mysql 的唯一索引 ，在我们的数据库层面保证不能重复下单  我可以控制是唯一的
同一个用户 针对于同一个商品只可以买一个  

重复下单 优化
我们
>1.使用数据库唯一索引 一旦是 2个请求   因为mysql 有行级锁你后面的插入的话 其实就会报错
>2. 我们下订单成功后 我就会吧当前用户存入redis中，后面的请求 我就不会访问db

首先 第一 我们的秒杀列表以及秒杀详情 我们从redis缓存中查询了，我们也解决了重复下单的问题
以及超卖的问题 我们此时再基于jmeter查看我们的qps，
 

我们秒杀时候 浏览器--->controller--->servcice--->db
针对于一个秒杀商品比如说有5000的qps，有10个请求到达service(我们通过redis 的incr)
如果秒杀商品多的话，比如说 你一个场次的商品更多  请求会更多
##>
同一个时间太多请求过来了 我们此时要做一个流量 的削峰
我们使用mq 来对我们的请求的异步处理.我们异步下单

我们可以做集群处理 我们可以海量接受请求 不至于单个被打崩了
我们应用程序发送消息后  消息是异步的  不知道消息的执行结果
##> 
如何通知我们浏览器 的执行结果呢##>>>>>>>>>>
因为我们是bs 架构  是浏览器和服务器  服务器无法主动给浏览器推送消息的
浏览器要想获取服务器的响应信息，必须要发送http请求
##>>>>
我浏览器 它有一个定时器，周期性的执行我们的函数，比如说0.5s执行一次

我们可以采用mq 来实现 针对于一个商品有50个 请求， 有很多秒杀商品同时参与
一个秒杀商品我们放10个请求去操作我们的db， 呢么针对于同一个10点场次的秒杀商品 同时抢购的话
最终就会把我们的db打崩溃了
我们此时就需要做流量的削峰  我们会使用mq对我们的请求进行异步处理
我们可以在服务端做集群，去消费mq的消息
我们也可以在客户端做集群，都往mq 中发消息
我们使用mq来异步处理我们的下单请求，


异步下单之后我们要解决一些问题

1>contreooler---->servie---->dao===>数据库，
我们也仅仅吧我们的消息发送到mq了，但是我们并不知道我们消息的执行结果，

我怎么通知我用户的执行结果呢
因为我们是bs架构,只能浏览器发送数据到服务器。  服务器无法主动给浏览器推送消息的
我们有什么方案 让用户知道我们的下单结果
> 浏览器有定时功能 每隔0.5s 发个请求获取用户的订单结果

我们可以通过定时任务来循环获取这样的结果  但是 存在的问题就是 循环几次
时间多长一些呢

还有就是长连接的场景， 通过websocket 实现 服务器的推送

我们浏览器和服务器建立一个长连接  当你服务器有消息后会主动进行推送
我们可以使用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 浏览器和服务器之间的长连接 实现浏览器和长连接的建立连接 实现消息推送

我们要在websocket服务端建立会话关系，websocket 服务端 有一个map集合  针对于我们的内容进行存储

建立连接之后 我们就可以通过websocket给客户端A 和客户端B 发送这样的消息
在map中寻找映射关系  然后再找到对应的session对象  进行通知到我们客户端

我们会吧消息异步发送给应用服务器，然后我们就会遇到问题，我们应用服务器不知道怎么通知到浏览器
>我们可以采用ajax 负责轮询
>我们可以采用websocket  相当于我浏览器和服务器之间可以建立长连接，我们可以实现浏览器和服务器建立连接之后怎么实现消息推送



我们bs结构服务端是没有办法主动发消息给客户端的，我们可以发请求响应 
或者 建立一个长连接 
我们基于这种方式实现了类似于服务端主动推送

 应对很多websocket连接 如何处理  单台机器很多websocket连接 对服务器的要求就会变大,
 我们可以在websocket 做集群，用ngixn 做转发  我们通过nginx 吧请求进行分发给websocket,基于hash进行分发
 

我们可以通过ngixn加集群的方式 来增加我们的能力， 应用程序端通过mq进行通知
找到就可以通知 找不到就不用通知了

Q2 我们客户端和服务器建立连接之后  如果没有主动关闭我们的窗口（连接一直存在）
我们建立好通道后  不发消息  连接会一直存在
我们可以采用客户端心跳的方式，发送心跳机制，来判断你客户端是否还存活
我要有心跳机制来检测你那些机器下线了，下线了就给他剔除了，类似于我们注册中心
付费的服务  我们可以采用付费的平台  goEasy

我们把应用改成了异步下单的这种方式， 我们要把下单改成异步mq下单,封装mq消息进行分发

我们改成了异步下单，我们之前相当于5000个请求打到服务端来，我们的目的是为了减少请求直接打到我们的
service，使用mq进行缓冲请求,
如果消费速度很慢的话我们可以设置集群

/
我们可以将秒杀成功或者秒杀失败的消息放入到mq  打个标签
10个库存 我多点了1个 只卖了9个  
这就是我们成功或者失败我们都要发送消息的

p120

springboot整合websocket,当我们建立连接之后把映射关系维护，map是县城不安全的
我们都操作同一个map的话，会出现线程不安全的问题，所以我们会用conneHashMap

我们通过事件的方式帮我们响应
我们找到我们的token来继续session发送消息

我们通过token就可以找到会话对象，然后把消息发送过去
我们可以通过websocket实现服务器向浏览器的主动推送
我们bs结构服务端是没有办法主动发消息给客户端的，我们可以发请求响应 
或者 建立一个长连接 
我们基于这种方式实现了类似于服务端主动推送
q1 应对很多websocket连接，我们该如何处理，单台机器很多websocket连接，对服务器的性能要求就很高

我们可以在websocket做集群，用nginx做转发,  我们通过nginx把请求进行分发给websocket,基于hash进行分发

我们可以通过ngixn加集群的方式 来增加我们的能力， 
应用程序端通过mq进行通知找到就可以通知 找不到就不用通知了


我们客户端和服务器建立连接之后  如果没有主动关闭我们的窗口（连接一直存在）
我们建立好通道后  不发消息  连接会一直存在

1>我们定时给客户端发送心跳包 心跳机制  我服务端怎么知道客户端是否还健康
我们可以采用心跳机制来判断 客户端是否还存在

我要有心跳机制来检测那些机器下线了  下线就可以剔除掉
类似于我们的注册中心
付费的服务  我们可以采用付费的平台  goEasy

 这样我们的流程就改成了异步下单的流程了，我们之前是相当于5000个服务同时打过来
 我们的目的是为了减少请求，直接打到service和直接打到数据库中
 我们使用Mq作为流量的缓冲， 对于消费过慢的的话我们可以采用集群的方式
 我们可以将秒杀成功或者秒杀失败的消息放入到mq  打个标签

同时我们需要监听失败还有超时取消的mq  因为我们失败之后我们需要将redis缓存进行加1 处理

我最终把消息推送给前端  异步下单后我们怎么排查我们的错误

预库存回补  我要做库存回补    因为我此时要做预库存回补


当我们成功后 我们会发延迟消息  当我们成功后如果没有支付我们会
## 支付超时的订单
过了10分钟还没有支付，我们要取消我们的订单 做库存回补
orderInfo.canalOrder() 根据订单编号判断是否有没有超时 
超时我们就取消订单




###############>>>>>>>>>>>>>>>>>
我们秒杀的逻辑   异步下单  我们是否要进行压测  我们加入mq 的目的是为了缓解并发的压力
异步下单的逻辑  比如说我们使用mq  redis  延时队列 tag 的过滤监听  websocket 的通知
>>>>>>>>.订单下单完毕后 我们要进行支付
我们可以依靠与支付宝的SDK 来做支付  依托于支付宝的沙箱环境

1.Q1 网站支付的流程 2.内网穿透
2,事务 spring是怎么感知我们的事物的  或者分布式事务

支付逻辑
	订单下达完毕后我们要做支付

我们的参数可能被别人拦截请求并且篡改 参数 我们要把我们的数据进行加密操作
支付宝采用的是非对称加密，加密分为对称加密和非对称加密
md5是单项的
我们可以使用公钥加密 私钥解密 或者我们可以使用私钥加密 公钥解密

#>对于支付宝来说 是私钥加密 公钥给别人 进行解密
要能实现回调 你的应用程序必须在互联网上是可见的

我们可以使用netApp做内网穿透

为什么我们的应用服务器是要求公网可见
因为此时支付成功后 支付宝会异步发请求发给我们的url

##>>
我们要实现接口的幂等性  就是执行多次 实际上只有1次
# 同一个订单 无论执行多少次 实际上只能执行一次
##  我们怎么实现幂等性  支付表 或者支付流水表  使用orderNo 作为唯一主键  
我们要保证我们的幂等性

在我们异步回调时候 如果我们没有收到支付宝的回调消息
我们要定位 为什么没有回调成功 可能是网络原因
此时我我们要提供一个接口 出现这种异常情况下 我们要进行人工补单

我们要在秒杀中做支付 此时我们还是服务的分离

前端--->秒杀--->支付--->支付宝

我们完成统一支付功能
我们把appid 配置在nacos上 （配置 私钥 公钥）

每个服务要传递自己的同步地址和异步,地址.因为在秒杀会处理我支付完毕的逻辑
会员服务会处理我们会员充值完毕之后的逻辑
同样我们基于feign发起的调用，同样我们如果调用失败了 我们要有PayFeignApi做回调


我们要搞清楚它的支付流程  以及理解它的支付逻辑
比如说支付中的交易参数 我们平台的敏感数据是怎么做的
我们使用的非堆成加密  私钥加密 公钥解密