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

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

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

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

import java.util.Random;

public class OrderRequest {
    private int goodId = new Random().nextInt(100000);// 商品id
    private int userId = new Random().nextInt(100000);// 用户ID
    private int status;// 0:未处理;1:正常;2:异常

    public int getGoodId() {
        return goodId;
    }

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

    public int getUserId() {
        return userId;
    }

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

    public int getStatus() {
        return status;
    }

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

}

2.controller 入口:

import java.util.concurrent.ConcurrentLinkedQueue;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.ReentrantLock;

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class QueueController {

    private static ConcurrentLinkedQueue<OrderRequest> orderQueue = new ConcurrentLinkedQueue<OrderRequest>();

    private static AtomicInteger totalprodocut;
    private static AtomicInteger totalQueSize;
    private ExecutorService excutorService = Executors.newCachedThreadPool();
    public static ReentrantLock queueLock = new ReentrantLock(true);

    static {
        totalprodocut = new AtomicInteger(15);
        totalQueSize = new AtomicInteger(15);
    }

    @RequestMapping("/queque")
    public String queque(OrderRequest orderRequest) {
        try {
            // queueLock.lock();
            if (totalprodocut.get() < 1) {
                return "error";
            } else {
                if (orderQueue.size() < totalQueSize.get()) {
                    // System.out.println(orderRequest.getGood_id()+" 增加到待处理队列成功:" + orderQueue.size());
                    orderQueue.add(orderRequest);
                } else {
                    return "error";
                }
            }
            if (!OrderDealThread.dealLock.isLocked()) {
                OrderDealThread dealQueue = new OrderDealThread(orderQueue);
                excutorService.execute(dealQueue);
            }
        } catch (Exception e) {
            e.printStackTrace();
            return "not done";
        } finally {
            // queueLock.unlock();
        }
        return "ok";
    }
}

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

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

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

3.业务处理线程

import java.util.Iterator;
import java.util.concurrent.ConcurrentLinkedQueue;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.ReentrantLock;

public class OrderDealThread implements Runnable {

    ConcurrentLinkedQueue<OrderRequest> orderQueue;

    private static AtomicInteger totalprodocut;

    public static ReentrantLock dealLock = new ReentrantLock(true);

    static {
        totalprodocut = new AtomicInteger(15);
    }

    public OrderDealThread() {
    }

    public OrderDealThread(ConcurrentLinkedQueue<OrderRequest> queque) {
        this.orderQueue = queque;
    }

    @Override
    public void run() {
        while (!orderQueue.isEmpty()) {
            try {
                dealLock.lock();
                Iterator<OrderRequest> it = orderQueue.iterator();
                while (it.hasNext()) {
                    dealQueque(it.next());
                }
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                dealLock.unlock();
            }
        }
    }

    void dealQueque(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万个?  疑问解除,原来我线程组里面循环了10次 没注意到那个参数

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

欢迎指正

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

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

=============增加=====================

有同学给我发邮件提了一个问题:

问:你代码里面请求进入了请求队列就返回了成功,但是你写了请求队列中请求数会超过预期值,那我怎么做下一步的操作呢?比如进行付款?

答:很好的问题!  感谢你的提问

说下处理逻辑:1.进入了请求队列,就有可能被请求到,而且这里是异步,就是说请求收到ok了,但后台逻辑完全可能还没处理

        所以,在接收到OK后,前端应该发起一个类似倒计时页面,如下:

        提示系统正常处理中,同时隔一定时间去后台确认是否处理完成以及状态

        当获取到的状态为完成且成功时,跳转到下一步如付款操作界面,现在很多秒杀系统都是这么处理的

我的博客即将搬运同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=bunl3uhohufn

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏coolblog.xyz技术专栏

Java CAS 原理分析

CAS 全称是 compare and swap,是一种用于在多线程环境下实现同步功能的机制。CAS 操作包含三个操作数 -- 内存位置、预期数值和新值。CAS...

788220
来自专栏進无尽的文章

编码篇-使用GDataXMLNode解析XML数据

在实际的开发中数据解析是很普遍的事,一般网络请求返回的数据有两种格式:XML和JSON。关于JSON的解析已是主流,满大街的解析方式。而XML的数据格式确实是很...

14910
来自专栏Charlie's Road

Mac端Wireshark抓包工具使用扩展

关于网络协议和网络分层,本篇文章不做介绍,仅记录使用,可能中间有理解错误的地方,请指正。

16220
来自专栏比原链

剥开比原看代码17:比原是如何显示交易的详细信息的?

Gitee地址:https://gitee.com/BytomBlockchain/bytom

8810
来自专栏JAVA高级架构

最全技术面试180题:阿里11面试+网易+百度+美团!

19710
来自专栏美团技术团队

Node.js Stream - 进阶篇

在构建较复杂的系统时,通常将其拆解为功能独立的若干部分。这些部分的接口遵循一定的规范,通过某种方式相连,以共同完成较复杂的任务。譬如,shell通过管道|连接各...

44740
来自专栏极客生活

macOS扫雷逆向破解

其中安全帽只有10个,用完了之后就需要在App Store进行购买,同时「高级」和「自定义」功能也需要在应用商店进行购买才可以玩。

14920
来自专栏JavaEdge

Redis实现分布式锁Redis分布式锁安全和活性失效保障为什么基于故障转移的实现还不够Redis分布式锁防死锁单Redis实例实现分布式锁的正确方法Redlock算法这个算法是异步的么?失败时重试释

58380
来自专栏技术小讲堂

Singal Page App:使用Knockout和RequireJS创建高度模块化的单页应用引擎背景知识文档结构服务端API准备Require配置与系统配置模块中的工作模块间的工作烂图赏鉴代码送上

开篇扯淡 距离上一篇文章已经有好几个月,也不是没有时间记录点东西,主要是换了新的工作,在一家外资工作,目前的工作内容大多都是前端开发,新接触的东西因为时间原因,...

32360
来自专栏Golang语言社区

Golang事务模型

序言 笔者在《软件设计的演变过程》一文中,将通信系统软件的DDD分层模型最终演进为五层模型,即调度层(Schedule)、事务层(Transaction DSL...

47550

扫码关注云+社区

领取腾讯云代金券