项目中使用队列

项目中使用队列

队列的作用

处理和响应速度、数据的一致性问题

队列采用的是线程安全的队列LinkedBlockingQueue，通过新的线程异步处理这些请求

“如果响应状态是卖完了，直接提示客户，如果请求已经放入队列中，就可以根据用户id和商品id去轮询订单了”

查询队列相关资料时

接触到一个新名词JUC，java.util.concurrent包的简称,在Java5.0添加,目的就是为了更好的支持高并发任务。提供便利的函数和功能、结构，让开发者进行多线程编程时减少竞争条件和死锁的问题!

应用

将接口请求放入队列中，对其进行处理

将接口调用请求队列化，可以避免出现线程疯抢CPU的情况，同时数据有序处理。

接口队列化的实现，初步想法，将接口的请求塞入到队列中，先进先出的原则，按序一个个处理请求，

将请求体放入到队列中了怎么请求响应是一个问题，从对列中获取的请求体，不知道是哪一个方法请求的

网上查找内容为针对某一个接口的队列化

梳理一下

接口的队列化分为两种

1对所有接口访问时均填充到队列中

2对某一个接口访问时，将请求内容放入到队列中，再获取请求内容 对数据做响应

舍弃方法2

验证方法2时，队列的大小总是为1，无法满足接口队列化的实际意义，响应内容和响应体不好对应

把接口看作一个个体，将该个体放入队列进行请求

执行耗时较长时，请求先入队列，接口方法到队列中获取请求个体在进行操作数据返回

尝试引入拦截器实现该功能

对请求进行拦截，对访问指定接口的请求个体存入队列中，接着从队列输出

类似于从水管中间的某一处截取装加水流限流装置，河道的闸口

什么都不做改变，只是管理水流量

引入kafka做流量削峰操作

这里注意一个思路的局限性，前面考虑的都是在一个服务里，当我们在服务a、服务b之间进行服务的调用时，可以在a和b之间引入队列，a将请求放入队列中，b从队列中取值操作

这里有问题点

a是否成功放入，b是否成功取出，b操作数据后怎么知道该返回给哪个调用端。

当操作a时，并发连接数

并发连接数，就是同一时刻[并发]系统支持的可用连接通道

比如并发连接数为10，就表示最多有十个链接同时连接到服务器，如果一个网站只有一个请求的话，就是最多10个人去打开这个网站，如果有11个人同时打开这个网站，第11个请求就会等待，直到前面的连接被断开

TPS--吞吐量、QPS--每秒查询率、RT--响应时间

目前对接口队列化的理解，以后更正

为了应对高峰访问量，将服务a拆分成服务b、c或者一个子功能一个服务，而服务b、c整体而言访问量是不变的，b、c之间的访问量也近似理解为高访问量，所以它们之间的调用可以使用队列进行缓冲，对于c的接口而言，就是接口队列化；对于用户访问b而言，这里就是服务器连接数，硬件问题了，选用nginx比tomcat支持的并发数多

 对服务器中启用的项目，该服务占用了一个进程，其本身包含了一系列的线程，对外界访问的连接数，虽然理论上是一个连接服务器会对应分配一个线程，但是实际上还是一个一个进行的访问，这和postman并发测试，但是服务中用拦截器计算访问量时，它是依次递增，而且是响应完上一个请求才接入下一个请求，这是个同步请求，不是那种交替执行的。

接口响应的快慢可以加线程影响，而且线程的数量不会因为并发的连接数过多而增多，进入一个服务是等待上一个请求完成才会进行下一个请求，现阶段最好的解决方案了。

如果是复制一份b一起操作c，对于b而言是两个进程这是另外的思路了，现讨论一份a分裂b、c。