從構建分佈式秒殺系統聊聊Lock鎖使用中的坑

前言

在單體架構的秒殺活動中，爲了減輕DB層的壓力，這裏咱們採用了Lock鎖來實現秒殺用戶排隊搶購。然而很不幸的是儘管使用了鎖，可是測試過程當中仍然會超賣，執行了N屢次發現依然有問題。輸出一下代碼吧，可能你們看的比較真切：

@Service("seckillService")
public class SeckillServiceImpl implements ISeckillService {
    /**
     * 思考：爲何不用synchronized
     * service 默認是單例的，併發下lock只有一個實例
     */
    private Lock lock = new ReentrantLock(true);//互斥鎖 參數默認false，不公平鎖
    @Autowired
    private DynamicQuery dynamicQuery;

    @Override
    @Transactional
    public Result  startSeckilLock(long seckillId, long userId) {
         try {
            lock.lock();
            //這裏、不清楚爲啥、老是會被超賣10一、難道鎖不起做用、lock是同一個對象
            String nativeSql = "SELECT number FROM seckill WHERE seckill_id=?";
            Object object =  dynamicQuery.nativeQueryObject(nativeSql, new Object[]{seckillId});
            Long number =  ((Number) object).longValue();
            if(number>0){
                nativeSql = "UPDATE seckill  SET number=number-1 WHERE seckill_id=?";
                dynamicQuery.nativeExecuteUpdate(nativeSql, new Object[]{seckillId});
                SuccessKilled killed = new SuccessKilled();
                killed.setSeckillId(seckillId);
                killed.setUserId(userId);
                killed.setState(Short.parseShort(number+""));
                killed.setCreateTime(new Timestamp(new Date().getTime()));
                dynamicQuery.save(killed);
            }else{
                return Result.error(SeckillStatEnum.END);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }finally {
            lock.unlock();
        }
        return Result.ok(SeckillStatEnum.SUCCESS);
    }
}

代碼寫在service層，bean默認是單例的，也就是說lock確定是一個對象。感受不放心，仍是打印一下 lock.hashCode()，輸出結果沒問題。因爲還有其餘事情要作，最終仍是帶着疑問提交代碼到碼雲。

追蹤

若是想分享代碼並使你們一塊兒參與進來，必定要自薦，這樣纔會被更多的人發現。固然，若是有交流羣必定要留下聯繫方式，這樣討論起來可能更方便。項目被推薦後，果真加羣的小夥伴就多了。因爲項目配置好相應參數就能夠測試，而且每一個點都有相應的文字註釋，其中有心的小夥伴果真注意到了我寫的註釋<這裏、不清楚爲啥、老是會被超賣10一、難道鎖不起做用、lock是同一個對象>，而後提出了困擾本身好多天的問題。

碼友zoain說，測試了很久終於發現了問題，原來lock鎖是在事物單元中執行的。看到這裏，小夥伴們有沒有恍然大悟，反正我是悟了。這裏，總結一下爲何會超賣101：秒殺開始後，某個事物在未提交以前，鎖已經釋放(事物提交是在整個方法執行完)，致使下一個事物讀取到了上個事物未提交的數據，也就是傳說中的髒讀。此處給出的建議是鎖上移，也就是說要包住整個事物單元。

AOP+鎖

爲了包住事物單元，這裏咱們使用AOP切面編程，固然你也能夠上移到Control層。

自定義註解Servicelock：

@Target({ElementType.PARAMETER, ElementType.METHOD})    
@Retention(RetentionPolicy.RUNTIME)    
@Documented    
public  @interface Servicelock { 
     String description()  default "";
}

自定義切面LockAspect:

@Component
@Scope
@Aspect
public class LockAspect {
    /**
     * 思考：爲何不用synchronized
     * service 默認是單例的，併發下lock只有一個實例
     */
    private static  Lock lock = new ReentrantLock(true);//互斥鎖 參數默認false，不公平鎖  

    //Service層切點     用於記錄錯誤日誌
    @Pointcut("@annotation(com.itstyle.seckill.common.aop.Servicelock)")  
    public void lockAspect() {

    }

    @Around("lockAspect()")
    public  Object around(ProceedingJoinPoint joinPoint) { 
        lock.lock();
        Object obj = null;
        try {
            obj = joinPoint.proceed();
        } catch (Throwable e) {
            e.printStackTrace();
        } finally{
            lock.unlock();
        }
        return obj;
    } 
}

切入秒殺方法：

@Service("seckillService")
public class SeckillServiceImpl implements ISeckillService {
    /**
     * 思考：爲何不用synchronized
     * service 默認是單例的，併發下lock只有一個實例
     */
    private Lock lock = new ReentrantLock(true);//互斥鎖 參數默認false，不公平鎖
    @Autowired
    private DynamicQuery dynamicQuery;

    @Override
    @Servicelock
    @Transactional
    public Result startSeckilAopLock(long seckillId, long userId) {
        //來自碼雲碼友<馬丁的早晨>的建議 使用AOP + 鎖實現
        String nativeSql = "SELECT number FROM seckill WHERE seckill_id=?";
        Object object =  dynamicQuery.nativeQueryObject(nativeSql, new Object[]{seckillId});
        Long number =  ((Number) object).longValue();
        if(number>0){
            nativeSql = "UPDATE seckill  SET number=number-1 WHERE seckill_id=?";
            dynamicQuery.nativeExecuteUpdate(nativeSql, new Object[]{seckillId});
            SuccessKilled killed = new SuccessKilled();
            killed.setSeckillId(seckillId);
            killed.setUserId(userId);
            killed.setState(Short.parseShort(number+""));
            killed.setCreateTime(new Timestamp(new Date().getTime()));
            dynamicQuery.save(killed);
        }else{
            return Result.error(SeckillStatEnum.END);
        }
        return Result.ok(SeckillStatEnum.SUCCESS);
    }
}

全部的工做完成之後，咱們來測試一下代碼，意料之中，再也沒有出現超賣的現象。然而，你覺得就這麼結束了麼？細心的碼友IM核米，又提出瞭如下問題：Spring 裏的切片在未指定排序的時候，兩個註解是隨意執行的。若是事務在加鎖前執行的話，是否是就會產生問題？

首先，因爲本身實在沒有時間去取證，最終仍是碼友IM核米完成了自問自答，這裏引用下他的解釋：

我說的沒錯，但 @Transactional 切片是特殊狀況

1）多 AOP 之間的執行順序在未指定時是 ：undefined ，官方文檔並無說必定會按照註解的順序進行執行，只會按照 @ Order 的順序執行。

可參考官方文檔： 能夠在頁面裏搜索 Command+F「7.2.4.7 Advice ordering」https://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/aop.html#aop-ataspectj-advice-ordering

2）事務切面的 default Order 被設置爲了 Ordered.LOWEST_PRECEDENCE，因此默認狀況下是屬於最內層的環切。

可參考官方文檔： 能夠在頁面裏搜索 Command+F「Table 10.2. tx:annotation-driven/ settings」 https://docs.spring.io/spring/docs/3.0.x/reference/transaction.html#transaction-declarative-txadvice-settings

總結

• 經驗真的很重要，踩的坑多了也變走成了路
• 不要吝嗇本身的總結成果，分享交流纔可以促使你們共同進步
• 最好不要懷疑久經考驗的Lock鎖同志，頗有多是你使用的方式不對

思考

爲何沒有用synchronized？

代碼案例：從0到1構建分佈式秒殺系統