redis隊列

---

# 一、redis隊列？ redis的發(fā)布訂閱模式 發(fā)送者 (pub) 發(fā)送消息，訂閱者 (sub) 接收消息。Redis 客戶端可以訂閱任意數(shù)量的頻道。 Redis的發(fā)布訂閱模式本質(zhì)和傳統(tǒng)的MQ的發(fā)布訂閱類似，但是相對于其它幾款MQ產(chǎn)品來說， redis的使用更加便捷，也更加輕量化，不需要單獨去搭建集成一套繁重的MQ框架。 但缺點也很明顯，redis發(fā)布的消息不會持久化，所以當某一臺服務(wù)器出現(xiàn)問題的時候， 這個消息會丟失，所以在考慮使用之前要慎重，當前的業(yè)務(wù)是否對數(shù)據(jù)一致性要求很高，如果要求很高，還是建議使用MQ產(chǎn)品。 介紹redis命令： SUBSCRIBE，用于訂閱信道PUBLISH，向信道發(fā)送消息UNSUBSCRIBE，取消訂閱 用于退訂給定的一個或多個頻道的信息。 語法： UNSUBSCRIBE channel

這種模式有如下的優(yōu)缺點：
優(yōu)點
典型的廣播模式，一個消息可以發(fā)布到多個消費者
多信道訂閱，消費者可以同時訂閱多個信道，從而接收多類消息
消息即時發(fā)送，消息不用等待消費者讀取，消費者會自動接收到信道發(fā)布的消息
缺點
消息一旦發(fā)布，不能接收。換句話就是發(fā)布時若客戶端不在線，則消息丟失，不能尋回
不能保證每個消費者接收的時間是一致的
若消費者客戶端出現(xiàn)消息積壓，到一定程度，會被強制斷開，導(dǎo)致消息意外丟失。通常發(fā)生在消息的生產(chǎn)遠大于消費速度時
可見，Pub/Sub 模式不適合做消息存儲，消息積壓類的業(yè)務(wù)，而是擅長處理廣播，即時通訊，即時反饋的業(yè)務(wù)。
思考如果我們使用這種模式讓api服務(wù)作為消息的發(fā)布者（pub）而所有的server作為服務(wù)的訂閱者（sub）可不可以，為什么？

明顯如果每個服務(wù)都接收到了請求，就會出現(xiàn)短信重復(fù)發(fā)送的情況，這不是我們期望的效果

lpush、lpop、rpush、rpop、lrange
Lpush 命令將數(shù)據(jù)插入到隊列頭部
格式：
LPUSH key “數(shù)據(jù)”
Rpush 命令用于將一個或多個值插入到列表的尾部(最右邊)。
格式：
Rpush key “數(shù)據(jù)”
Lpop 命令用于移除并返回列表的第一個元素
格式：
Lpop key
Rpop 命令用于移除列表的最后一個元素，返回值為移除的元素
格式：
RPOP key

Lrange 返回列表中指定區(qū)間內(nèi)的元素，可以指定一個區(qū)間以偏移量 START 和 END 指定。 其中 0 表示列表的第一個元素， 1表示列表的第二個元素，以此類推也可以使用負數(shù)下標，以-1表示列表的最后一個元素，-2表示列表的倒數(shù)第二個元素，以此類推。格式：LRANGE key START END

首先我們來看一個現(xiàn)象，當我們通過lpop命令或rpop命令從一個空的隊列中獲取數(shù)據(jù)
我們看到如果隊列是空的 通過lpop和rpop命令直接返回了空

我們思考對于我們的系統(tǒng)來說有沒有問題a)api服務(wù)接收到數(shù)據(jù)后通過lpush命令往key中添加數(shù)據(jù)b)server服務(wù)通過rpop命令從隊列中獲取數(shù)據(jù)有沒有問題？為什么？存在什么問題，資源浪費問題如何解決？介紹blpop，brpopblpop、brpop：相比于rpop和lpop多了b（b代表blocking）及阻塞的意思，阻塞讀在隊列沒有數(shù)據(jù)的時候進入休眠狀態(tài),當隊列為空時，lpop和rpop會一直空輪訓(xùn)，消耗資源；所以引入阻塞讀blpop和brpop（b代表blocking），阻塞讀在隊列沒有數(shù)據(jù)的時候進入休眠狀態(tài)，一旦數(shù)據(jù)到來則立刻醒過來，消息延遲幾乎為零。

總結(jié)

以上是生活随笔為你收集整理的了解redis队列原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。