這期內(nèi)容當中的小編將會給大家?guī)碛嘘Predis中的消息隊列介紹，以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

古丈網(wǎng)站建設公司成都創(chuàng)新互聯(lián),古丈網(wǎng)站設計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為古丈超過千家提供企業(yè)網(wǎng)站建設服務。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務好的古丈做網(wǎng)站的公司定做！

一、認識消息隊列

1.1 消息隊列概念

“消息”是在兩臺計算機間傳送的數(shù)據(jù)單位。消息可以非常簡單，例如只包含文本字符串；也可以更復雜，可能包含嵌入對象。

消息被發(fā)送到隊列中?！跋㈥犃小笔窃谙⒌膫鬏斶^程中保存消息的容器。消息隊列管理器在將消息從它的源中繼到它的目標時充當中間人。隊列的主要目的是提供路由并保證消息的傳遞；如果發(fā)送消息時接收者不可用，消息隊列會保留消息，直到可以成功地傳遞它。

1.2 核心結構

由一個業(yè)務系統(tǒng)進行入隊，把消息逐次插入到消息隊列中，插入成功之后直接返回成功的結果，后續(xù)會有一個消息處理系統(tǒng)，這個系統(tǒng)會把消息系統(tǒng)中的記錄逐次進行取出并進行處理，完成一個出隊的流程。

1.3 應用場景

數(shù)據(jù)冗余：比如訂單系統(tǒng)，后續(xù)需要嚴格的進行數(shù)據(jù)轉換和記錄，消息隊列可以把這些數(shù)據(jù)持久化的存儲在隊列中，然后有訂單，后續(xù)處理程序進行獲取，后續(xù)處理完之后在把這條記錄進行刪除來保證每一條記錄都能夠處理完成。

系統(tǒng)解耦：使用消息系統(tǒng)之后，入隊系統(tǒng)和出隊系統(tǒng)是分開的，也就說只要一天崩潰了，不會影響另外一臺系統(tǒng)正常運轉。

流量削峰：例如秒殺和搶購，我們可以配合緩存來使用消息隊列，能夠有效的頂住瞬間訪問量，防止服務器承受不住導致崩潰。

異步通信：消息本身使用入隊之后可以直接返回。

擴展性：例如訂單隊列，不僅可以處理訂單，還可以給其他業(yè)務使用。

排序保證：有些場景需要按照產(chǎn)品的順序進行處理比如單進單出從而保證數(shù)據(jù)按照一定的順序處理，使用消息隊列是可以的。

以上都是消息隊列常見的使用場景，當然消息隊列只是一個中間件，可以配合其他產(chǎn)品進行使用。

1.4 常見隊列實現(xiàn)優(yōu)缺點

隊列介質(zhì)

1、數(shù)據(jù)庫，例如MySQL（可靠性高，易實現(xiàn)，速度慢）

2、緩存， 例如redis （速度快，單個消息報包過大時效率低）

3、消息系統(tǒng)，例如rabbitMq （專業(yè)性強，可靠，學習成本高）

消息處理觸發(fā)機制

1、死循環(huán)方式讀?。阂讓崿F(xiàn)，故障時無法及時恢復；（比較適合做秒殺，比較集中，運維集中維護）

2、定時任務：壓力均分，有處理上限；目前比較流行的處理觸發(fā)機制。（唯一的缺點是間隔和數(shù)據(jù)需要注意，不要等上一個任務沒有完成下一個任務又開始了）

3、守護進程：類似于php-fpm 和php-cg,需要shell基礎

1.5進程通信

消息隊列（也叫做報文隊列）能夠克服早期unix通信機制的一些缺點。作為早期unix通信機制之一的信號能夠傳送的信息量有限，后來雖然POSIX 1003.1b在信號的實時性方面作了拓廣，使得信號在傳遞信息量方面有了相當程度的改進，但是信號這種通信方式更像"即時"的通信方式，它要求接受信號的進程在某個時間范圍內(nèi)對信號做出反應，因此該信號最多在接受信號進程的生命周期內(nèi)才有意義，信號所傳遞的信息是接近于隨進程持續(xù)的概念（process-persistent）；管道及有名管道則是典型的隨進程持續(xù)IPC，并且，只能傳送無格式的字節(jié)流無疑會給應用程序開發(fā)帶來不便，另外，它的緩沖區(qū)大小也受到限制。

消息隊列就是一個消息的鏈表。可以把消息看作一個記錄，具有特定的格式以及特定的優(yōu)先級。對消息隊列有寫權限的進程可以向消息隊列中按照一定的規(guī)則添加新消息；對消息隊列有讀權限的進程則可以從消息隊列中讀走消息。消息隊列是隨內(nèi)核持續(xù)的。

目前主要有兩種類型的消息隊列：POSIX消息隊列以及系統(tǒng)V消息隊列，系統(tǒng)V消息隊列目前被大量使用?？紤]到程序的可移植性，新開發(fā)的應用程序應盡量使用POSIX消息隊列。

系統(tǒng)V消息隊列是隨內(nèi)核持續(xù)的，只有在內(nèi)核重起或者顯式刪除一個消息隊列時，該消息隊列才會真正被刪除。因此系統(tǒng)中記錄消息隊列的數(shù)據(jù)結構（struct ipc_ids msg_ids）位于內(nèi)核中，系統(tǒng)中的所有消息隊列都可以在結構msg_ids中找到訪問入口。 消息隊列就是一個消息的鏈表。每個消息隊列都有一個隊列頭，用結構struct msg_queue來描述。隊列頭中包含了該消息隊列的大量信息，包括消息隊列鍵值、用戶ID、組ID、消息隊列中消息數(shù)目等等，甚至記錄了最近對消息隊列讀寫進程的ID。讀者可以訪問這些信息，也可以設置其中的某些信息。

二、解藕案例：隊列處理“訂單系統(tǒng)”和“配送系統(tǒng)”

對于訂單流程，我們可以設計兩個系統(tǒng)，一個是“訂單系統(tǒng)” 另外一個是 “配送系統(tǒng)”， 在網(wǎng)購的時候我們應該都見過，當我提交了一個訂單之后，我在后臺可以看到我的貨物正在配送中。這個時候就要參與進來一個“配送系統(tǒng)”。

如果我們在做架構的時候把 “訂單系統(tǒng)” 和 “配送系統(tǒng)” 設計在一起的話就會出現(xiàn)一些問題，首先對于訂單系統(tǒng)來說，因為系統(tǒng)的壓力會比較大，但是 "配送系統(tǒng)" 沒必要為這些壓力做一些即時的反應。

第二個我們也不希望在訂單系統(tǒng)出現(xiàn)故障之后導致配送系統(tǒng)也出現(xiàn)故障，這個時候就會同時影響到兩個系統(tǒng)的正常運轉。所以我們希望把這兩個系統(tǒng)進行解耦。這兩系統(tǒng)分開之后我們可以通過一個中間的 “隊列表” 進行這兩個系統(tǒng)的溝通。

2.1 架構設計

1、首先訂單系統(tǒng)會接收用戶的訂單，然后進行訂單的處理。

2、然后會把這些訂單信息寫到隊列表中，這個隊列表是溝通這兩個系統(tǒng)的關鍵。

3、由配送系統(tǒng)定時執(zhí)行的一個程序來讀取隊列表進行處理。

4、配送系統(tǒng)處理之后，會把已處理的記錄進行標記。

2.2 程序流程

三、流量削峰案例：Redis 的 list 類型實現(xiàn)秒殺

redis 基于內(nèi)存，它的速度會非?？欤瑀edis 對數(shù)據(jù)庫有一個非常好的補充作用因為它是可持久化的，redis會周期性的把數(shù)據(jù)寫到硬盤里，所以它不用擔心斷電的問題，從這方面說它比另一款緩存 memcache 更有優(yōu)勢些，另外 redis 提供五種數(shù)據(jù)類型（字符串，雙向鏈表，哈希，集合，有序集合）

一般情況下，做秒殺案例，搶購，瞬間高比你高發(fā)，需要排隊 的案例中 redis是一個很好的選擇。

3.1 redis數(shù)據(jù)類型中的 list 類型

redis 的list 是一個雙向鏈表，可以從頭部或者尾部追加數(shù)據(jù)。

* LPUSH/LPUSHX :將值插入到（/存在的）列表頭部

* RPUSH/RPUSHX: 將值插入到（/存在的）列表尾部

* LPOP : 移除并獲取列表的第一個元素

* RPOP: 移除并獲取列表的最后一個元素

* LTRIM: 保留指定區(qū)間內(nèi)的元素

* LLEN: 獲取列表長度

* LSET: 通過索引設置列表元素的值

* LINDEX: 通過索引獲取列表中的元素

* LRANGE: 獲取列表指定范圍內(nèi)的元素

3.2 架構設計

一個簡單結構秒殺的程序設計。

1、首先記錄是哪一個用戶參與了秒殺同時記錄他的時間。

2、將用戶的id存到redis列表中，讓它排隊。如果規(guī)定只有前10個用戶可以參與成功，如果列表中的個數(shù)已經(jīng)夠了就不會讓它繼續(xù)追加數(shù)據(jù)。這樣redis的列表長度就只會是10個

3、最后在慢慢的將redis中的數(shù)據(jù)寫入到數(shù)據(jù)庫中，以減少數(shù)據(jù)的壓力

3.3 代碼級設計

1、當用戶開始秒殺時，將秒殺程序的請求寫入Redis (uid, time_stamp)中。

2、假使規(guī)定只有10人可以秒殺成功，檢查 Redis 已經(jīng)存放數(shù)據(jù)的長度，超出上限直接丟棄說明秒殺完成。

3、最后在死循環(huán)處理存入Redis中的10條數(shù)據(jù)，然后在慢慢的取數(shù)據(jù)并存入到mysql數(shù)據(jù)庫中。

在秒殺這一塊對于數(shù)據(jù)庫的壓力特別的大，如果我們沒有這樣的設計，會造成mysql的寫入瓶頸。我們通過Redis的一個對列l(wèi)ist，然后把秒殺的請求放入到Redis里面， 最后通過入庫程序，把數(shù)據(jù)慢慢的寫入到數(shù)據(jù)庫，這樣的話就可以實現(xiàn)流量的均衡，對mysql不會造成太大的壓力。　

四、RabbitMQ

這里講解一些RabbitMQ的使用，首先我們之前講秒殺案例的時候提到了鎖的機制，防止其他程序處理同一條記錄，如果我們的系統(tǒng)架構非常的復雜，有多個程序實時的讀取一個隊列，或者我有多個發(fā)送程序，同時來操作一個或多個隊列，甚至我還想這些程序分布在不同的機器上，這種情況下用redis隊列就有些力不從心了。這種時候怎么辦呢，我們就需要來引入一些更專業(yè)的消息隊列系統(tǒng)，這些系統(tǒng)可以更好的來解決問題。

4.1 RabbitMQ的架構和原理

特點：完整的實現(xiàn)了AMQP,集群簡化，持久化，跨平臺

RabbitMQS使用

1、RabbitMQ安裝 （rabbitmq-server, php-amqplib）

2、生產(chǎn)者向消息通道發(fā)送消息

3、消費者處理消息

工作隊列

思想：由生產(chǎn)者發(fā)送給消息系統(tǒng)，消息系統(tǒng)把任務封裝成消息隊列之后，然后供多個消費者使用同一個隊列

這不僅解決了生產(chǎn)者和消費者之間的解耦，還可以實現(xiàn)了消費者和任務的共享，減緩了服務器的壓力。

上述就是小編為大家分享的redis中的消息隊列了，如果您也有類似的疑惑，不妨礙參照上述分析進行理解。如果想了解更多相關內(nèi)容，請關注創(chuàng)新互聯(lián)行業(yè)資訊。