我的秒杀总结

关注

原创最新推荐文章于 2026-04-13 10:11:23 发布 942 阅读 AI 写同款· GEO 优化 ›

秒杀系统设计（学习）：从 “稳准快” 到落地的全流程方案秒杀系统设计的核心在于应对瞬时高并发请求，保证"稳、准、快"三大目标。通过分层优化策略：1）前端静态资源CDN缓存+动态数据本地暂存；2）接入层限流+应用层本地缓存；3）Redis预扣库存+消息队列削峰；4）数据库最终一致性校验。关键要解决超卖问题（Redis预扣+MySQL双重校验）和热点隔离（业务/系统/数据三层隔离）。兜底方案包括限流、熔断、降级和事后核对，确保系统高可用。整体设计遵循"层层过滤、抓大放小"原则，用简单方案解决核心问题。阅读详情

title: 我的秒杀总结
date: 2016-11-24 19:50:35
categories:

技术
tags:
实习

近期接到一个十万数量的秒杀任务，后台完全由我写。因为之前对秒杀的处理所知甚少，故趁此机会学习了一下。当然，这里秒杀只涉及到 “抢” 的环节，没有下单、支付等，故对性能要求不是那么高。最终，“跌跌撞撞”地还是让系统上线了，目前运行良好。

项目环境

两台业务的服务器，还有一台缓存服务器和一台数据库服务器。
在整个项目的前端部分自然离不开负载均衡。故这里还是采用 Nginx 来实现。具体方式采用默认的配置，即轮询的方式。

关于“抢”的环节

intro：一天分为几个时段开抢，每个时段有几分钟的时间抢（该时段的奖品抢完了或者时间到了，该时段抢购就结束了），对于没有抢完的奖品，要求自动“滚到”下一轮。

为了满足如上要求，自然得从数据库开始设计。在系统运行前，将十万奖品批量输入至数据库。我给所有奖品设计了一个生效时间 和一个 是否被抢 的标志。

这里我采用的技巧是（解决方案）：
每个奖品都有一个生效时间，这个生效时间是每个时间段的开始时间，只有当前时间大于生效时间该奖品才可以抢（具体可以用sql控制，这里时间采用ms，时间越往后时间越大）。

再声明一下抢奖品的策略：只有当前时间大于奖品的生效时间，该奖品才可以抢。这样设计解决了对于后面的几轮秒杀可以秒杀到之前没抢完的奖品（因为后面几轮的当前时间大于前面奖品的生效时间）的要求。同时，又可以避免前一时段的秒杀环节抢到后面时段的奖品。原因自然是当前时间比后面几轮的生效时间小。

性能方面：为了避免每一次都要去数据库查取符合条件的奖品（生效时间和是否被抢），++我自然需要将奖品一次性地多拿几个放到内存里++。这里我使用队列来存放符合条件的奖品，每来一个用户，抢走（弹出）队列头部的奖品。后面的用户来了再弹出一个。从而避免用户“同时”拿到同一个奖品，从而避免“超卖”现象。

那么队列我具体采用什么样的数据结构呢？如下
基于链接节点的无界线程安全队列（这个名字很霸气~~）

    private static volatile Queue<Coupon> couponQueue;
    static{
        if (null == couponQueue) {
            LOG.info("QueueServiceImpl init!!");
            couponQueue = new ConcurrentLinkedQueue<Coupon>(); 
            }
    }

具体弹出采用什么代码呢？

@Override
public  Coupon getPoll(String uid) {
    Coupon coupon = null;
    synchronized(this){
        coupon = couponQueue.poll();
        if (coupon == null) {
            setQueue();//从数据库里取奖品放入队列的方法
            coupon = couponQueue.poll();
        }
        if (coupon!=null){
            int row =  couponDao.allocateCoupon(coupon.getId(),uid,CouponConst.Status.USED,System.currentTimeMillis());

            if (row!=1){
                coupon = null;
            }
        }
    }
    //打日志
    if (coupon!=null) {
        LOG.info(
                "getPoll uid:{},couponId:{}",
                new Object[]{uid, coupon.getId()});
    }
    return coupon;
}

这里有个synchronized，是为了线程安全，避免多个人访问同一段代码产生冲突。
那么为什么把“弹出”（如果内存队列里没有了，还会去数据库里一次性取100奖品来放入内存）和update奖品是否被抢状态的代码同时锁住呢？

试想这样一种场景：内存里原本放100个奖品的队列，经过一段时间后还剩下两个奖品。此时，甲、乙两个用户过来弹出了最后的两个奖品，还未来的及修改奖品状态。此时此刻，丙冲了过来，结果发现队列里没有了，coupon==null，就去setQueue()从数据库里拿符合条件的100个奖品放入内存队列。然而！，甲乙还没来得及将其抢到的奖品修改状态，就是说这两个奖品还没有被标记已经抢过。所以这两个奖品又会被丙放入内存队列，接着弹出！由后来者再去抢。从而造成一种现象，最后的奖品被多个用户抢到，从而形成冲突。解决方案：加锁！

是不是这样就可以了呢？？

回答是No！因为我在学校一般都写的是一个业务服务器，这里是两个！亲，两个和一个有着巨大差别，这是放在内存里，不是缓存服务器里。所以A服务器取了100个符合条件的奖品，B服务器也取了100个符合条件的奖品，然而！，A和B可能取得都是前100个奖品，就是说，这俩服务器取得是相同的奖品，然后进行发放！怎么办呢？？

解决方案：我首先想到的是将奖品队列放入缓存服务器（1台）里？这样就避免冲突。可是缓存用的是 xmemcached，不是redis！没法支持那么多数据结构，而且xmemcached的CAS用起来并不舒服，，，
那么，该怎么处理呢~上代码：

    int flag = -1 ;//因为 线上有两台服务器， 所以 为避免两台服务器 取 相同的 coupon 放入自己的内存；故采用 id%2==flag 分开。

    int ip = LocalIPGetter.getLocalServerIpTail(); //获取当前服务器ip
    if (ip == 223) { //如果是A服务器 取id为奇数的奖品放入内存队列
        flag = 1;
    }else {         //如果是B服务器 取id为偶数的奖品放入内存队列
        flag = 0;
    }

    List<Coupon> couponList = couponDao.selectByStatusValidate(CouponConst.Status.INIT,current,100,flag); //两台服务器根据奇偶数进行分类去数据库取奖品。

上述代码就是我的解决思路,是不是太简单了点，把数据库表分成两块，两个服务器互不干扰。

还有缓存服务器，我将获奖者名单放在里面，减少对数据库的访问。

关于“抢”的环节多次点击问题

我遇到这样一个问题（一位用户只能秒杀成功一次）：

试想这样一个场景，对于某用户甲，点击了“秒杀”按钮。但是由于网速、性能等原因，用户甲比较着急，连续点了好几次。

当第一次请求发来时：数据库里没有该用户的记录，资格认证，发现没有秒杀记录，将要添加用户，想进入秒杀流程。注意：这里是将要，还没有添加用户。此刻！！！
该用户的第二次点击请求发了过来，资格认证，发现没有秒杀记录，将要添加用户。然而！！！第一次请求添加用户成功，第二次请求又来添加，数据库主键冲突！500！