Redis和请求队列解决高并发

背景

在移动互联网高速发展的时代，各种电商平台的抢购业务变得越来越火爆，抢购业务所带来的高并发问题值得我们去探索，主要涉及的方面包括处理和响应速度、数据的一致性等。抢购开放的一瞬间，可能有成千上万的下订单请求发送到服务器去处理，如果只是简单的请求处理响应方式，不做任何处理，导致的结果很可能是很多客户很长时间得不到响应，根本不知道自己是否下订单成功，或者下订单的数量已经超过了商品的数量，这就导致了超发的问题。

设计思路

用户在下订单之前当然是先查询到这个商品，在这个查询的时候，将数据库中商品的剩余数量存到redis中；

服务器在一瞬间接到成千上万的下订单请求，在控制层没有直接处理请求数据，而是先根据redis中商品的剩余数量来判断，如果>0,就将请求放到请求队列中，否则直接响应客户端“卖完了”；

考虑到数据的一致性，队列的容量就是商品的剩余数量，队列采用的是线程安全的队列LinkedBlockingQueue(单台服务器),然后通过新的线程异步处理这些请求，多台服务器的话,可以考虑使用消息队列MQ,单独用一台服务器去处理消息队列中的请求;

客户端发送订单请求之后，会收到响应，要么是剩余数量不足（卖完了），要么是请求已经被放到队列中,为下一步的轮询订单做准备;

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

实现步骤

说明：用java语言，springmvc框架+redis实现

• 准备工作，查询商品信息，将剩余数量同步到redis中

Jedis jedis = jedisPool.getResource();
BuyGood good=buyGoodService.getById(good_id);
jedis.set("residue"+good_id, good.getResidue()+"");
jedisPool.returnResource(jedis);

• 下订单的方法,下面直接展示代码，包括请求对象，控制层方法，请求处理线程类的具体实现

• 请求封装对象

public class BuyRequest {
    private int good_id;//商品id
    private int user_id;//用户ID
    private int order_id;//订单id
    private BuyOrders buyOrders;//订单信息
    private int response_status;//0:未处理;1:正常;2:异常

    public BuyOrders getBuyOrders() {
        return buyOrders;
    }

    public void setBuyOrders(BuyOrders buyOrders) {
        this.buyOrders = buyOrders;
    }