Redis消息隊列是什么意思

本篇內容介紹了“Redis消息隊列是什么意思”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

異步

異步的使用場景【符合我們的真實的世界，真實世界本來就是異步的】，生活中大部分的使用都是基于異步的，比如發送郵件與回復郵件的請求響應模型。

一個service與另外一個service有三種交互方式：命令（Commands）、事件（Events）以及查詢（Queries）。一次請求可以理解為由主服務與觸發服務和關聯服務組成。

Commands 。命令是一個操作。希望在另一個服務中執行某些操作的一個請求。 會改變系統狀態的東西。 命令期待有響應。

Events 。事件既是一個事實也是一個觸發器。 發生了一些事情，表示為通知。

Queries 。查詢是一個請求，是一個查找一些東西的請求（request）。重要的是，查詢不會使得系統狀態發生改變。

解耦

解耦的基礎含義倡導一種是由上而下，分而治之的思想。

解耦又是消息隊列最本質的目的。把消息的送達和處理分開，才真正實現消息系統的解耦。

基于消息的模型，關心的是通知，而非處理 。只關心核心流程，多個任務的情況下，發送通知就行了。

經典的生產者消費者模式的消息模型，通過Broker分離生產與消息，Broker簡單來說就是消息服務器，負責消息的接受，存取。可以這樣理解：

在服務型項目開發上，服務型項目的意思就是項目本質上不是單體應用，會為多個業務服務，上游對下游的調用，不直接通過觸發方式完成即可，而是通過消息中心隔離上下游


可靠

001

可靠性簡單來說就是程序把需要處理的任務進行編號，每個編號的任務在任務運行期間都是可以被跟蹤的。每一個任務擁有自己的唯一標記。比如命名規則可以是：業務組件名稱加時間戳的生成規則。

以下 我們看一個網絡資料的公開案例

用戶最近N條訂單記錄的Redis存儲

對于這個需求需要滿足幾個條件

1 消息需要有序存儲，來確定數據結構SortSet

2 全局跟蹤每條記錄，對數據進行唯一編碼

【訂單有序集合中的每個元素是將時間毫秒數+訂單號最后3位作為分數進行排序的。為什么不只用毫秒數作為分數呢？因為我們的下單時間只精確到秒，如果不加訂單號最后3位，若同一秒有兩個或兩個以上訂單時，排序分數就會一樣，從而導致根據分數從緩存查詢訂單時不能保證唯一性。而我們的訂單號的生成規則可以保證同一秒內的訂單號的最后3位肯定不一樣】

002

每個階段在處理任務時，都需要有任務回執，來表明這條任務的處理狀態，是處理成功還是失敗，還是別拒絕處理等。我們以SortSet集合為例，隊列處理消費時，一定是按照一定順序，從前往后或者從后往前依次N條的獲取，獲取之后，索取元素被消費程序處理，處理的結果如何就是前文提到的任務回執，如果這時因為網絡抖動或者調用鏈下游原因導致消費失敗，所取元素代表的業務元數據也會隨之消失。這時候就需要根據回執來判斷是否需要另外處理所取元素。

Redis下的發布訂閱

使用redis的pubsub功能，訂閱者訂閱頻道，發布者發布消息到頻道了，頻道就是一個消息隊列。

我們可以認為發布訂閱方式是一種實時的通訊模式。

001

redis 發布訂閱使用場景明顯是構建實時消息系統，依賴于redis服務端長連接的穩定性。php連接redis的長鏈接本身就是不靠譜的，而且pubsub也不能使用在可靠性要求比較高的系統中。【不靠譜】體現在訂閱模式服務器端開啟訂閱后，過一段時間訂閱會失效，需要不停的輪訓開啟訂閱。

針對Redis的發布訂閱功能，網上找到一種說明

一個生產者可以對應多個消費者，但是必須保證消息發布者和消息的訂閱者同時在線，否則，否則一旦消息訂閱者由于各種異常情況而被迫斷開連接，在其重新連接后，其離線期間的消息是無法被重新通知的（即發即棄）。

對于這種理解，最重要的是在應用開發中如何保證雙發都在線的長連接狀態？

002

對【不靠譜】的一種解釋如下：

因為Redis的監聽其實是打開了一個長連接操作的。任何網絡波動都會斷開的。服務器內網絡穩定的情況下是可以的。或者這么說更準確一些，redis做長連接不算是一種優選方案。

分布式

涉及到消息隊列的三個角色，發布者，Broker和消費者，都可以以集群的形式進行部署和發布。消費能力可以通過增加機器數進行擴展。

補充：根據參考文檔來

Q1：分布式消息系統中，如何避免消息重復？

造成消息重復的根本原因是：網絡不可靠。只要通過網絡交換數據，就無法避免這個問題。所以解決這個問題的辦法就是繞過這個問題。那么問題就變成了：如果消費端收到兩條一樣的消息，應該怎樣處理？

a. 消費端處理消息的業務邏輯保持冪等性;

b. 保證每條消息都有唯一編號且保證消息處理成功與去重表的日志同時出現。

通過冪等性，不管來多少條重復消息，可以實現處理的結果都一樣。再利用一張日志表來記錄已經處理成功的消息的ID，如果新到的消息ID已經在日志表中，那么就可以不再處理這條消息，避免消息的重復處理。

“Redis消息隊列是什么意思”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！