java将请求排队处理_【高并发】秒杀系统高并发请求排队处理

ゝ一世哀愁。 2022-11-09 11:24 367阅读 0赞

今天无意中看见了这位兄弟的文章 通过请求队列的方式来缓解高并发抢购(初探) 但文章最后说并发超过500 就会出现超发，看了下代码，的确有这个问题

抽空简单完善了下，经压力测试后发现暂无超发现象， 下面为我的代码，有不足之处请指正交流：

1.请求参数封装，有个随机的用户ID 用来区分不同用户的请求：

importjava.util.Random;public classOrderRequest \{private int goodId = new Random().nextInt(100000);//商品id

private int userId = new Random().nextInt(100000);//用户ID

private int status;//0:未处理;1:正常;2:异常

public intgetGoodId() \{returngoodId;

\}public void setGoodId(intgoodId) \{this.goodId =goodId;

\}public intgetUserId() \{returnuserId;

\}public void setUserId(intuserId) \{this.userId =userId;

\}public intgetStatus() \{returnstatus;

\}public void setStatus(intstatus) \{this.status =status;

2.controller 入口：

importjava.util.concurrent.ConcurrentLinkedQueue;importjava.util.concurrent.ExecutorService;importjava.util.concurrent.Executors;importjava.util.concurrent.atomic.AtomicInteger;importjava.util.concurrent.locks.ReentrantLock;importorg.springframework.web.bind.annotation.RequestMapping;importorg.springframework.web.bind.annotation.RestController;

@RestControllerpublic classQueueController \{private static ConcurrentLinkedQueue orderQueue = new ConcurrentLinkedQueue();private staticAtomicInteger totalprodocut;private staticAtomicInteger totalQueSize;private ExecutorService excutorService =Executors.newCachedThreadPool();public static ReentrantLock queueLock = new ReentrantLock(true);static\{

totalprodocut= new AtomicInteger(15);

totalQueSize= new AtomicInteger(15);

@RequestMapping("/queque")publicString queque(OrderRequest orderRequest) \{try\{//queueLock.lock();

if (totalprodocut.get() < 1) \{return "error";

\}else\{if (orderQueue.size()

orderQueue.add(orderRequest);

\}else\{return "error";

\}if (!OrderDealThread.dealLock.isLocked()) \{

OrderDealThread dealQueue= newOrderDealThread(orderQueue);

excutorService.execute(dealQueue);

\}catch(Exception e) \{

e.printStackTrace();return "not done";

\}finally\{//queueLock.unlock();

\}return "ok";

说明： 如果这里放开lock，可以保证只有允许的请求进入到请求队列中去，但是效率会降低很多，毕竟每个请求都要去上锁开锁

如果这里不要锁，进入请求队列的请求会超过我们设定的个数，但不会多太多；

其实这里应该不用锁，应该快速的响应大多数不能进入请求队列用户的请求，已经进入请求队列的请求在后续处理的时候还会进行业务判断的

3.业务处理线程

importjava.util.Iterator;importjava.util.concurrent.ConcurrentLinkedQueue;importjava.util.concurrent.atomic.AtomicInteger;importjava.util.concurrent.locks.ReentrantLock;public class OrderDealThread implementsRunnable \{

ConcurrentLinkedQueueorderQueue;private staticAtomicInteger totalprodocut;public static ReentrantLock dealLock = new ReentrantLock(true);static\{

totalprodocut= new AtomicInteger(15);

\}publicOrderDealThread() \{

\}public OrderDealThread(ConcurrentLinkedQueuequeque) \{this.orderQueue =queque;

@Overridepublic voidrun() \{while (!orderQueue.isEmpty()) \{try\{

dealLock.lock();

Iterator it =orderQueue.iterator();while(it.hasNext()) \{

dealQueque(it.next());

\}catch(Exception e) \{

e.printStackTrace();

\}finally\{

dealLock.unlock();

\}voiddealQueque(OrderRequest orderRequest) \{if (orderRequest.getStatus() == 0) \{int status = 2;if (totalprodocut.get() > 0) \{//需再次判断是否还有商品，加锁范围内//TODO 下单处理其他逻辑

totalprodocut.decrementAndGet();//减库存

status =1;

\}if (status == 2) \{//System.out.println(orderRequest.getUserId() + " deal er:" + Thread.currentThread().getName());

orderRequest.setStatus(2);

\}else\{

System.out.println(orderRequest.getUserId()+ " deal ok:" +Thread.currentThread().getName());

orderRequest.setStatus(1);

说明：在真正处理业务的时候还要判断是否有库存等逻辑

上述代码中，部分内容，比如产品数目等应该在活动开始前同步到redis等能快速获取的中间件中去

下面是我的测试结果：有个疑问？ 我设置的线程组是1秒内启动6000个，为啥这里显示6万个

![ef30082257fe9d11ba6d64e3a16e657f.png][]

经过多轮测试，暂未发现多发现象， OK项目始终只有15个

![b1413267b00c245ebf2c373c418f3c9b.png][]

欢迎指正

由于是在windows下测试，并发高了就报错 java.net.BindException: Address already in use 这个初看上去很像端口被占用，其实是因为已经完成请求的 socket 端口 还处于 TIME\_WAIT状态，把端口耗尽了

处理办法 参考 https://blog.csdn.net/ywb201314/article/details/51258777

原文：https://www.cnblogs.com/xiaochangwei/p/miaosha.html

[ef30082257fe9d11ba6d64e3a16e657f.png]: /images/20221023/a09c9054d43a4c9f929bb1621700b535.png
[b1413267b00c245ebf2c373c418f3c9b.png]: /images/20221023/dcc009601aa945b684da61ceb21ba1d2.png