php佇列處理：php訊息佇列實作原理（圖文）

php隊列是什麼意思？怎麼實現的？有哪些應用場景？以下透過使用mysql實作解耦案例和使用redis進行流量削鋒案例詳細講解php訊息佇列的實作原理。

佇列的概念：

1、是佇列結構的中間件

2、訊息放入後不需要立即處理

3、由訂閱者/消費者依序處理

佇列原理：

#也是解耦的原理：業務系統和佇列處理系統沒有關係

一個寫（業務系統），一個讀（隊列管理系統）。

寫的只管往佇列裡寫，別的不用操心，讀的能不能讀完和寫的也沒有關係

同樣，讀的只管從隊列裡往外讀，來活兒就乾，沒活兒歇著

應用場景：

冗餘：持久化的儲存在佇列中，後續由訂單處理程序獲取，處理完成之後，在把這條記錄進行刪除

解耦：是解這2套系統（業務和佇列處理），我們平常做的都是一套系統的。入隊和出隊的系統沒有直接的關係，其中一套蹦了，另一套系統不會受影響，因為中間隔了個佇列

流量削鋒：秒殺和搶購。流量劇增，配合快取使用訊息佇列（就是限制下，如只允許10個，佇列存10個之後就不存了，在來就提示秒殺結束）

非同步通訊：因為訊息本身就可使入隊的系統直接返回，所以說實現了程式的非同步操作

場景擴展性：如 現在只有訂單系統和財務系統，後續我想加個配貨系統，直接讓配貨系統訂閱這個隊列就可以

##排序保證：有些場景下，如 銀行資料的處理順序是很重要的，因為佇列本身就可以做成單線程，單進單出的這種系統

#實作媒體：

1、使用mysql：可靠性高，易實現，速度慢

2、使用redis：速度快，單一大訊息包時效率低

3、使用更專業的第三方類別函式庫：專業性強，可靠，學習成本高。

訊息處理觸發機制：

1、死循環方式讀取：易實現，故障時無法及時回覆（

適用於秒殺這種短時間的）

2、定時任務：壓力均分，有處理上限（無論你隊列前的系統，峰值多麼不穩定，

隊列後的系統依然會定時執行 )

注意：定時時間是個關鍵：不要上一個還定時任務沒執行完，下一個定時任務就啟動了

案例：訂單系統，下單後將訂單資訊寫入佇列後，立刻回到下單成功。配貨系統每隔幾分鐘

定時讀取佇列，對訂單進行匯總處理

3、守護程式：類似php-fpm和cgi，需要shell基礎（用這個程式來偵測，佇列中是否有內容，有內容的話，啟動出隊系統進行處理）

使用mysql實作解耦案例：

為什麼要解耦：如果架構在一起。訂單系統壓力大，而物流資訊是不需要立刻回來的。訂單崩了，物流也就彈了，所以要解耦

訂單系統寫入佇列的程式碼：

######配貨系統讀取佇列的程式碼：###

執行定時任務Crontab -e

注意：這日誌檔案要自己新建

#1、透過瀏覽器訪問order.php新增訂單

2、去資料庫看結果，在shell中的日誌中看結果(沒有執行成功，可能是這sh檔需要放在某個特點目錄吧，等複習完在跑)

#使用redis進行流量削鋒案例

想法：

1、秒殺程序請求寫入redis    
2、檢查redis已存放資料的長度，超出上限直接丟棄（返回秒殺結束）

3、死循環處理存入redis的資料併入庫

表格的設計：

#秒殺程式碼：

入庫程式碼：

瀏覽器直接存取user.php

在

shell

中使用

php -f savetodb.php

####去資料庫查看###### 相關推薦：############################################################# PHP 訊息佇列服務######

以上是php佇列處理：php訊息佇列實作原理（圖文）的詳細內容。更多資訊請關注PHP中文網其他相關文章！