最近公司要做一個秒殺活動匪补，結(jié)合大量的預熱然后估算了現(xiàn)目前的網(wǎng)站真實用戶數(shù)據(jù)溃卡，結(jié)合我們一系列的數(shù)據(jù)統(tǒng)計后（這里面就不一一細講了，大致就是平時的峰值流量的150%）币绩，我們得出的是qps在300左右蜡秽。其實這流量并不算高，我們就沒有采用rebittmq這些專門的消息隊列來進行處理缆镣，因為學習成本較高芽突，而且并不是特別的需要，所以我們決定用redis的list來進行消息隊列的實現(xiàn)费就。
這里講一點題外話诉瓦，redis依舊發(fā)布的5.+版本中有一個stream流的類型，那么這個是什么呢力细。Redis Stream本質(zhì)上是在Redis內(nèi)核上（非Redis Module）實現(xiàn)的一個消息發(fā)布訂閱功能組件。相比于現(xiàn)有的PUB/SUB固额、BLOCKED LIST眠蚂，其雖然也可以在簡單的場景下作為消息隊列來使用，但是Redis Stream無疑要完善很多斗躏。Redis Stream提供了消息的持久化和主備復制功能逝慧、新的RadixTree數(shù)據(jù)結(jié)構(gòu)來支持更高效的內(nèi)存使用和消息讀取、甚至是類似于Kafka的Consumer Group功能。Redis Stream是一個作者已經(jīng)謀劃多年的feature笛臣，本質(zhì)是一個消息隊列云稚，但是和kafka、RocketMq等消息中間件相比也有其獨特之處沈堡。Redis Stream本來是計劃放在4.0這個大版本中發(fā)布（原計劃4.2）,但是由于確實是個比較重磅的feature静陈，對內(nèi)核的改動也比較大，目前已經(jīng)提升到Redis 5.0發(fā)布
所以以后大家可以盡可能的多使用redis的消息隊列了诞丽，像我這種懶人就不喜歡去為了一個功能實現(xiàn)去搞一堆復雜的東西鲸拥，傳言說的是redis的stream的某些方面處理數(shù)據(jù)的性能可以接近甚至超過kafka的處理能力，所以我們的大數(shù)據(jù)也完全可以處理了僧免，但是目前來說刑赶，就我所接觸到的公司都還沒開始正式投入使用，可以等一段時間后各大社區(qū)開始投入使用后懂衩，我會出一篇具體的文章來蹭蹭熱度撞叨。
首先吐槽下自己吧，這篇文章本來打算昨天就應該發(fā)了浊洞，結(jié)果不小心關(guān)機了（沒電谒所，心里是萬馬奔騰，是我在代碼上寫了很多注釋都沒保存沛申，哎）首先我們講講我們的原理吧劣领，我們首先在服務端起一個php服務，監(jiān)控秒殺隊列铁材，如果有數(shù)據(jù)進入list隊列中尖淘，就將數(shù)據(jù)讀取到數(shù)據(jù)庫。下面就是簡單的demo示例著觉，我們主要用的linux環(huán)境村生。
首先·是我們的秒殺代碼，秒殺開始主要走這里的邏輯饼丘。這里沒啥可講的趁桃。
服務端監(jiān)控代碼。我們可以在秒殺前1小時進行服務開啟肄鸽，也可以用定時任務進行啟動卫病，當然時間就可能不是1小時了。此處我們就是執(zhí)行了一個死循環(huán)不斷的讀取list的值典徘，當記錄值i的值為10的時候進行終止程序蟀苛。讀取的值呢我們可以進行排隊發(fā)短信或者存入數(shù)據(jù)庫之類的。
我們開始試驗逮诲，首先帜平，我們開啟腳本幽告，在終端執(zhí)行php redis_contab.php
因為服務器是新配置的，所以我直接在終端操作裆甩，執(zhí)行插入數(shù)據(jù)
然后呢冗锁，監(jiān)控端就可以看見這個了
其實這里代碼還有很多可以進行優(yōu)化的，這里我只是提出的一個樣板嗤栓，一般消息隊列需要一定的容錯性冻河，就是如果一個人從rpop彈出來，插入到數(shù)據(jù)庫失敗抛腕，那么這個人應該被lpush到redislist隊列中去芋绸。
