Redis消息隊列是什么意思

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

異步

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

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

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

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

Queries 。查詢是一個請求，是一個查找一些東西的請求（request）。重要的是，查詢不會使得系統(tǒng)狀態(tài)發(fā)生改變。

解耦

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

解耦又是消息隊列最本質(zhì)的目的。把消息的送達和處理分開，才真正實現(xiàn)消息系統(tǒng)的解耦。

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

經(jīng)典的生產(chǎn)者消費者模式的消息模型，通過Broker分離生產(chǎn)與消息，Broker簡單來說就是消息服務器，負責消息的接受，存取?？梢赃@樣理解：

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


可靠

001

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

以下 我們看一個網(wǎng)絡資料的公開案例

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

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

1 消息需要有序存儲，來確定數(shù)據(jù)結構SortSet

2 全局跟蹤每條記錄，對數(shù)據(jù)進行唯一編碼

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

002

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

Redis下的發(fā)布訂閱

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

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

001

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

針對Redis的發(fā)布訂閱功能，網(wǎng)上找到一種說明

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

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

002

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

因為Redis的監(jiān)聽其實是打開了一個長連接操作的。任何網(wǎng)絡波動都會斷開的。服務器內(nèi)網(wǎng)絡穩(wěn)定的情況下是可以的?；蛘哌@么說更準確一些，redis做長連接不算是一種優(yōu)選方案。

分布式

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

補充：根據(jù)參考文檔來

Q1：分布式消息系統(tǒng)中，如何避免消息重復？

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

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

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

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

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