推薦教程：《redis視頻教程》

一、背景

先看看一下業務場景：

1.會員過期前3天發送召回通知

2.訂單支付成功后，5分鐘后檢測下游環節是否都正常，比如用戶購買會員后，各種會員狀態是否都設置成功

3.如何定期檢查處于退款狀態的訂單是否已經退款成功？

4.實現通知失敗，1，3，5，7分鐘重復通知，直到對方回復？

通常解決以上問題，最簡單直接的辦法就是定時去掃表。

掃表存在的問題是：

1.掃表與數據庫長時間連接，在數量量大的情況容易出現連接異常中斷，需要更多的異常處理，對程序健壯性要求高

2.在數據量大的情況下延時較高，規定內處理不完，影響業務，雖然可以啟動多個進程來處理，這樣會帶來額外的維護成本，不能從根本上解決。

3.每個業務都要維護一個自己的掃表邏輯。 當業務越來越多時，發現掃表部分的邏輯會重復開發，但是非常類似

延時隊列能對于上述需求能很好的解決

二、調研

調研了市場上一些開源的方案，以下：

1.有贊科技：只有原理，沒有開源代碼

2.github個人的：https://github.com/ouqiang/delay-queue

1.基于redis實現，redis只能配置一個,如果redis掛了整個服務不可用，可用性差點2.消費端實現的是拉模式，接入成本大，每個項目都得去實現一遍接入代碼3.在star使用的人數不多，放在生產環境，存在風險，加之對go語言不了解，出了問題難以維護

3.SchedulerX-阿里開源的： 功能很強大，但是運維復雜，依賴組件多，不夠輕量

4.RabbitMQ-延時任務: 本身沒有延時功能，需要借助一特性自己實現，而且公司沒有部署這個隊列，去單獨部署一個這個來做延時隊列成本有點高，而且還需要專門的運維來維護，目前團隊不支持

基本以上原因打算自己寫一個，平常使用php多，項目基本redis的zset結構作為存儲，用php語言實現 ，實現原理參考了有贊團隊：https://tech.youzan.com/queuing_delay/

整個延遲隊列主要有4個部分：

1.JobPool用來存放所有Job的元信息。

2.DelayBucket是一組以時間為維度的有序隊列，用來存放所有需要延遲的Job（這里只存放Job Id）。

3.Timer負責實時掃描各個Bucket，并將delay時間大于等于當前時間的Job放入到對應的Ready Queue。

4.ReadyQueue存放處于Ready狀態的Job（這里只存放JobId），以供消費程序消費。

消息結構 每個Job必須包含一下幾個屬性：

1.topic：Job類型?？梢岳斫獬删唧w的業務名稱。

2.id：Job的唯一標識。用來檢索和刪除指定的Job信息。

3.delayTime：jod延遲執行的時間，13位時間戳

4.ttr（time-to-run)：Job執行超時時間。

5.body：Job的內容，供消費者做具體的業務處理，以json格式存儲。

對于同一類的topic delaytime,ttr一般是固定，job可以在精簡一下屬性

1.topic：Job類型。可以理解成具體的業務名稱

2.id：Job的唯一標識。用來檢索和刪除指定的Job信息。

3.body：Job的內容，供消費者做具體的業務處理，以json格式存儲。

delaytime,ttr在topicadmin后臺配置

三、目標

輕量級：有較少的php的拓展就能直接運行，不需要引入網絡框架，比如swoole，workman之類的

穩定性：采用master-work架構，master不做業務處理，只負責管理子進程，子進程異常退出時自動拉起

可用性：

1.支持多實例部署，每個實例無狀態，一個實例掛掉不影響服務

2.支持配置多個redis，一個redis掛了只影響部分消息

3.業務方接入方便，在后臺只需填寫相關消息類型和回調接口

拓展性: 當消費進程存在瓶頸時，可以配置加大消費進程數，當寫入存在瓶頸時，可增加實例數寫入性能可線性提高

實時性：允許存在一定的時間誤差。

支持消息刪除：業務使用方，可以隨時刪除指定消息。

消息傳輸可靠性：消息進入到延遲隊列后，保證至少被消費一次。

寫入性能：qps 1000+

四、架構設計與說明

總體架構

采用master-work架構模式，主要包括6個模塊：

1.dq-mster: 主進程，負責管理子進程的創建，銷毀，回收以及信號通知

2.dq-server: 負責消息寫入，讀取，刪除功能以及維護redis連接池

3.dq-timer-N: 負責從redis的zset結構中掃描到期的消息，并負責寫入ready 隊列，個數可配置，一般2個就行了，因為消息在zset結構是按時間有序的

4.dq-consume-N: 負責從ready隊列中讀取消息并通知給對應回調接口，個數可配置

5.dq-redis-checker: 負責檢查redis的服務狀態，如果redis宕機，發送告警郵件

6.dq-http-server: 提供web后臺界面，用于注冊topic

五、模塊流程圖

消息寫入:

timer查找到期消息:

consumer消費流程:

六、部署

環境依賴：PHP 5.5+ 安裝sockets，redis，pcntl,pdo_mysql 拓展

ps: 熟悉docker的同學可以直接用鏡像: shareclz/php7.2.14 里面包含了所需拓展

step1:安裝數據庫用于存儲一些topic以及告警信息

執行:

mysql source dq.sql

step2:在DqConfg.文件中配置數據庫信息： DqConf::$db

step3: 啟動http服務

在DqConf.php文件中修改php了路徑 $phpBin

命令：

php DqHttpServer.php --port 8088

訪問:http://127.0.0.1:8088,出現配置界面

redis信息格式：host:port:auth 比如 127.0.0.1:6379:12345

step4:配置告信息(比如redis宕機)

step5:注冊topic

重試標記說明:

1.接口返回為空默認重試2.滿足指定返回表達會重試，res表示返回的json數組，比如:回調接口返回json串：{ code :200, data :{ status :2, msg : 返回失敗 }}，重試條件可以這樣寫 {res.code}!=200  {res.code}!=200 {res.data.status}!=2  {res.code}==200 {res.data.status}==2 || {res.data.msg}== 返回失敗 

step6:啟動服務進程:

php DqInit.php --port 6789 

執行 ps -ef | grep dq 看到如下信息說明啟動成功

step7: 寫入數據，參考demo.php

step8:查看日志

默認日志目錄在項目目錄的logs目錄下，在DqConf.php修改$logPath

1.請求日志：request_ymd.txt

2.通知日志：notify_ymd.txt

3.錯誤日志：err_ymd.txt

step9:如果配置文件有改動

1.系統會自動檢測配置文件新，如果有改動，會自動退出(沒有找到較好的熱更新的方案)，需要重啟，可以在crontab里面建個任務,1分鐘執行一次，程序有check_self的判斷

2.優雅退出命令: master檢測偵聽了USR2信號，收到信號后會通知所有子進程，子進程完成當前任務后會自動退出

ps -ef | grep dq-master| grep -v grep | head -n 1 | awk {print $2} | xargs kill -USR2

七、性能測試

需要安裝pthreads拓展：

測試原理：使用多線程模擬并發，在1s內能成功返回請求成功的個數

php DqBench concurrency requestsconcurrency:并發數requests： 每個并發產生的請求數測試環境：內存 8G ，8核cpu，2個redis和1個dq-server 部署在一個機器上，數據包64字節qps：2400

八、值得一提的性能優化點：

1.redis multi命令：將多個對redis的操作打包成一個減少網絡開銷

2.計數的操作異步處理，在異步邏輯里面用函數的html' target='_blank'>static變量來保存，當寫入redis成功后釋放static變量，可以在redis出現異常時計數仍能保持一致，除非進程退出

3.內存泄露檢測有必要: 所有的內存分配在底層都是調用了brk或者mmap，只要程序只有大量brk或者mmap的系統調用，內存泄露可能性非常高 ,檢測命令:

strace -c -p pid | grep -P mmap| brk 

4.檢測程序的系統調用情況：strace -c -p pid ，發現某個系統函數調用是其他的數倍，可能大概率程序存在問題

推薦參考：《Redis命令操作中文手冊》

九、異常處理

1.如果調用通知接口在超時時間內，沒有收到回復認為通知失敗，系統會重新把數據放入隊列，重新通知，系統默認最大通知10次(可以在Dqconf.php文件中修改$notify_exp_nums)通知間隔為2n+1，比如第一次1分鐘，通知失敗，第二次3分鐘后，直到收到回復，超出最大通知次數后系統自動丟棄，同時發郵件通知

2.線上redis每隔1s持久化一次，存在丟失1s數據的情況，出現這種情況可以對比request_ymd.txt和notify_ymd.txt日志手動恢復過來

3.redis宕機通知:

ps:網絡抖動在所難免，通知接口如果涉及到核心的服務,一定要保證冪等??！

十、線上情況

線上部署了兩個實例每個機房部一個，4個redis共16G內存作存儲，服務穩定運行數月，各項指標均符合預期

主要接入業務:

訂單10分鐘召回通知

調用接口超時或者失敗時做補償

會員過期前3天召回通知

十一、不足與展望

1.由于團隊使用的鏡像缺少libevent拓展，所以dq-server基于select模型，并發高的場景下性能存在瓶頸，后續可以改為基于libevent事件模型，提升并發性能

2.timer和consumer目前是采用多進程來做的，這個粒度感覺有點粗，可以考慮使用多線程模式，并且支持動態創建線程數來提高consumer的性能，最大程度保證消費及時

3.dq-server與redis是同步調用，這也是性能的瓶頸點，計劃基于swoole_redis來異步處理

[更新]

一、測試網絡框架切換到swoole和使用異步swoole_redis帶來的性能改變情況 把dqserver的主要邏輯基于swoole重新寫了一遍，測試機(內存4G,cpu個數4)

啟動sever:

php test_swoole_server.php 9055

壓測:

php test_swoole_bench.php 100 56

結果:

1.原生dq-server: qps 2200

2.基于swoole swoole_redis: qps 5600

寫入性能提升:2.6倍

引入swoole性能提升比較明顯，不過目前暫時不打算把server改為swoole的方式，主要基于以下考慮

1.目前我們線上單個示例的qps3000，部署了兩個，6000ps可以滿足我們大部分場景

2.目前對swoole處于了解的過程

二、新增隊列消費分優先級（高，中，低3級），高優任務可以優先消費 消費比例在DqConf::$priorityConfig配置，默認按照5：3：2的比例消費

推薦相關redis視頻教程：

《燕十八redis視頻教程》

《傳智播客redis基礎視頻教程》

《黑馬云課堂NoSQL之Redis技術視頻教程》

《NoSql-redis基礎視頻教程》

《麥子學院深入淺出 redis 視頻教程》

感謝PHP 熱心網友的投稿，其GitHub地址為：https://github.com/chenlinzhong/php-delayqueue

以上就是基于php和redis實現的延遲隊列的詳細內容，PHP教程

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。