标签：判断 情况 带来 bsp ref consumer strong href 按钮
答：
高并发简单的来说就是在同一时刻不同用户访问同一资源的问题，专业一点的说法就是在同一时刻有多个线程访问了同一个数据资源。
答：
也许我们可以用锁来解决并发的问题，但是锁无疑带来的是效率的低下，用户体验也极低。我们想要的是快速返回，但是后面那一堆的逻辑怎么办呢？我们可以使用RabbitMq队列，用户的请求到达了抢单接口，我们只向队列中丢一条数据后就立即返回
这时又来了一个问题，会有同一个用户多次进行请求的情况，如果像之前的逻辑，前10条信息有二条是属于一个人的呢，（这里假设每个人只可以购买一次）我们就需要进行判断了，同一个账户发送的多次请求，我们只认为第一次请求是有效的，剩下的都请都直接返回。因为是并发，我们又怎么做到第一次请求有效呢？这时我们可以使用Redis incr存储用户的标识，Redis是单线程的，不存在并发的问题。incr返回为1那么是第一次请求，为N则是第N请求那么它就是无效的。这是请求标识
请求标识我们可以在抢单接口就进行判断，也就是先拿用户的标识去Incr，返回为1则丢到队列，不为1则不丢到队列。
也可以在rabbitmq的消费端进行处理，从rabbitmq消息队列中拿到用户信息后，进行incr。再进行下一步操作
丢到了消息队列中，我们还需要去处理，consumer我们肯定是要有多个的，我们可以使用平分分发与手动交付。在这里我们把用户的信息进行入库，当然入库后我们再向Redis中存入一条入库标识
上面都是在后端，客户端这里点击了抢单按钮后可以立即导向排队界面（是不是很熟悉，某米。。。）在这个界面进行轮询五秒一次，判断当前用户在库中的位置，如果是前十，那么就进行订单操作，不是。。。那就再等，看看会不会有其他用户放弃购买资格。
其实讲到这里，已经差不多了，成功的把并行变成了串行。剩下的就是业务处理，怎么做都可以。其实对于并发还可以有其它的处理方式，比如乐观锁也可以有效的控制并发。
更详细的可以：https://www.cnblogs.com/sheseido/p/11243323.html
标签：判断 情况 带来 bsp ref consumer strong href 按钮
原文地址：https://www.cnblogs.com/mvpbest/p/13288536.html
