消息隊列的場景

我們都知道，消息是在兩臺計算機(jī)之間傳送的數(shù)據(jù)單位，這個“消息”可以非常簡單，例如只包含文本字符串，也可以更復(fù)雜，可能包含嵌入對象。而所謂的“消息隊列”是在消息的傳輸過程中保存消息的容器。在web程序中，可能我們需要將用戶的請求數(shù)據(jù)更新或者添加到數(shù)據(jù)庫中，但是在高炳發(fā)的情況下，雖然作為用戶的我們不知道后臺是什么原因，但是依舊會抱怨或者吐槽這個程序反應(yīng)緩慢，比如在過去的幾年里，你有沒有吐槽過12306搶票很難？反應(yīng)很慢？有沒有在使用某個程序的時候收到“service is too busy”,而這其實(shí)是因為當(dāng)時的并發(fā)訪問過量，超過了系統(tǒng)的最大負(fù)載能力。當(dāng)然我們可以通過添加服務(wù)器集群中服務(wù)器的數(shù)量來增加程序的負(fù)載能力。

過度耦合的缺點(diǎn)：php應(yīng)用中，過度的耦合使得系統(tǒng)拓展性變?nèi)酰?lián)動性錯誤。

今天我給大家介紹的是利用redis的隊列消息實(shí)現(xiàn)模塊間的解耦。

應(yīng)用場景：用戶在采購模塊下單買了一批貨物回來，簽收時要在倉庫模塊添加相應(yīng)的庫存，普通的做法就是在簽收完成的時候通過接口給倉庫模塊推送數(shù)據(jù)執(zhí)行入庫操作。但是這么做如果倉庫模塊發(fā)送錯誤，沒有入庫成功就會導(dǎo)致采購模塊簽收失敗，這就是耦合給系統(tǒng)帶來的缺點(diǎn)。

解決方案：運(yùn)用php+redis隊列消息的技術(shù)，當(dāng)用戶簽收成功的時候，把數(shù)據(jù)放入隊列中，入列成功采購模塊則返回簽收成功的提示給用戶，后續(xù)的操作都不需要采購模塊操心，然后倉庫系統(tǒng)可以通過redis的訂閱發(fā)布模式來進(jìn)行監(jiān)聽，當(dāng)有數(shù)據(jù)入列，則倉庫系統(tǒng)就執(zhí)行入庫邏輯代碼的

運(yùn)行。

關(guān)鍵點(diǎn)：

1、如果redis服務(wù)器掛掉了怎么辦啊？

在采購模塊的簽收邏輯代碼中做判斷，如果入列成功則返回簽收完成，如果入列失敗這運(yùn)行傳統(tǒng)方法，通過接口入庫的方法。如果redis也掛了，倉庫模塊也掛了怎么辦啊，那你就收拾包袱回家吧。

2、如何實(shí)現(xiàn)傳統(tǒng)方式那樣實(shí)時入庫啊？

采用redis的訂閱發(fā)布模式就可以解決。訂閱的代碼放在倉庫模塊，發(fā)布的代碼放在采購模塊。

訂閱代碼sub.php

?php
$redis = new Redis();
$redis->connect('localhost', 6379);
$redis->subscribe(['ruku'], function ($redis, $chan, $msg) {//訂閱入庫頻道　　　if($msg==2500){　　 //如果監(jiān)聽到有發(fā)布信息則從隊列中拿取信息進(jìn)行入庫操作 　　 。。。。。。。  }　　
});

發(fā)布代碼pub.php

?php
$redis = new Redis();
$redis->connect('localhost', 6379);
$order = ['id' => 1, 'name' => '小米6', 'price' => 2499, 'created_at' => '2017-07-14'];$redis->lpush('order',$order);
$redis->publish("ruku", 2500);

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。