摘要：秒殺接下來是關(guān)鍵的一步，使用的是的命令獲取商品，利用的是的原子性。好的方面是秒殺成功的數(shù)量是準(zhǔn)確的，沒有超賣。參考資料實(shí)現(xiàn)高并發(fā)下的搶購秒殺功能基于云原生的秒殺系統(tǒng)設(shè)計思路秒殺架構(gòu)設(shè)計

秒殺想必大家都了解，在短時間內(nèi)請求訪問會激增，同時要保證不會超賣和數(shù)據(jù)的準(zhǔn)確，對于技術(shù)方面還是有些考驗(yàn)的?？上У氖?，一直沒有機(jī)會在項目中實(shí)現(xiàn)。再看了一些資料后，打算實(shí)驗(yàn)下。以下代碼僅為測試所用，環(huán)境比較簡單，請根據(jù)實(shí)際情況進(jìn)行修改。

在開始秒殺之前，先將商品放入隊列中，如下

/**
     * 創(chuàng)建秒殺列表
     */
    public function createList()
    {
        $count = 30;
        $redisKey = "goods_list";

        for ($i = 1; $i <= $count; $i++) {

            // 測試用，防止數(shù)據(jù)錯誤
            if (Redis::llen($redisKey) >= $count) {
                break;
            }

            Redis::rpush($redisKey, $i);
        }
    }

執(zhí)行完后，在 Redis 中看下

有 30 個商品 ID，數(shù)據(jù)正常。

接下來是關(guān)鍵的一步，使用的是 Redis 的 lpop 命令獲取商品 ID，利用的是 Redis 的原子性。

/**
     * 秒殺
     */
    public function buy()
    {
        // 隨機(jī)用戶名，無意義，僅做標(biāo)記
        $username = Hash::make(now());

        if ($goodsId = Redis::lpop("goods_list")) {
            // 購買成功
            Redis::hset("buy_success", $goodsId, $username);
        } else {
            // 購買失敗
            Redis::incr("buy_fail");
        }
    }

如上，簡化了代碼，購買之后，成功與否只是做記錄。實(shí)際應(yīng)用中，當(dāng)然會更加復(fù)雜，但要注意的是，不要同步操作 Mysql。多說一句，Hash:make(now()) 即使值相同，也不會生成相同的數(shù)據(jù)，參考這里。

最后就是進(jìn)行測試了，使用 ab 測試，執(zhí)行 ab -c 300 -n 3000 http://localhost/buy/ ，上述命令的意思是 300 并發(fā)，共請求 3000 次

執(zhí)行完成，速度并不快，并且還有 794 個訪問失敗。來看下數(shù)據(jù)是否正確吧。在頁面中打印 buy_success 值

30 個成功者。再來看下秒殺失敗的數(shù)量

不是一個準(zhǔn)確的數(shù)字，2165+30 是所有請求成功的數(shù)字，再加上失敗的 794 ，總數(shù)是 2989，依然不足 3000。

上述測試有不足的地方，響應(yīng)速度慢、請求失敗、失敗計數(shù)不準(zhǔn)確?？磥碛泻芏嘁獌?yōu)化的地方，不止是代碼層。測試的時候忘記將訪問記錄入庫關(guān)掉，應(yīng)該是有些影響。
好的方面是秒殺成功的數(shù)量是準(zhǔn)確的，沒有超賣。

重新配置了環(huán)境， 測試了同樣的代碼。不同的地方是增加了每次訪問判斷是否在黑名單（實(shí)時查詢 MySQl），而訪問記錄改成了隊列寫入 MySQL。結(jié)果如下

對比來看還是有所提升的。最主要的是數(shù)據(jù)終于是正確的，訪問失敗 355，搶購成功 30，搶購失敗 2615（忘記截圖了），相加總數(shù)正好是請求總數(shù)。而且 MySQL 中記錄的訪問記錄也是 3000。

參考資料：Redis實(shí)現(xiàn)高并發(fā)下的搶購、秒殺功能、基于云原生的秒殺系統(tǒng)設(shè)計思路、秒殺架構(gòu)設(shè)計