首頁 >后端開發 >php教程 > 正文

基于php和redis實現的延遲隊列

原創2019-11-13 17:54:5115339
第十期線上培訓班
基于redis實現高可用,易拓展,接入方便,生產環境穩定運行的延遲隊列。延遲隊列,顧名思義它是一種帶有延遲功能的消息隊列。 那么,是在什么場景下我才需要這樣的隊列呢?

推薦教程:《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),以供消費程序消費。

delaythird.png

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

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

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+

四、架構設計與說明

總體架構

jiagou.png

采用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

五、模塊流程圖

消息寫入:

xieru.png

timer查找到期消息:

scan.png

consumer消費流程:

xiaofei.png

六、部署

環境依賴: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,出現配置界面

index.png

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

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

warning.png

step5:注冊topic

topic2.png

重試標記說明:

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}=='返回失敗'

topiclist.png

step6:啟動服務進程:

php DqInit.php --port 6789 &

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

list.png

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  requests
concurrency:并發數
requests: 每個并發產生的請求數
測試環境:內存 8G ,8核cpu,2個redis和1個dq-server 部署在一個機器上,數據包64字節
qps:2400

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

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

2.計數的操作異步處理,在異步邏輯里面用函數的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宕機通知:

redisdown.png

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中文網其它相關文章!

php中文網最新課程二維碼
  • 相關標簽:php redis延遲隊列
  • 本文原創發布php中文網,轉載請注明出處,感謝您的尊重!
  • 相關文章

    相關視頻


    網友評論

    文明上網理性發言,請遵守 新聞評論服務協議

    我要評論條評論
    。。
  • 。。· 2019-08-22 20:00:121樓
  • 謝謝啊 居然還要6個字

  • 專題推薦

    推薦視頻教程
  • Redis命令操作中文手冊Redis命令操作中文手冊
  • 傳智播客redis基礎視頻教程傳智播客redis基礎視頻教程
  • Redis參考手冊Redis參考手冊
  • 黑馬云課堂NoSQL之Redis技術視頻教程黑馬云課堂NoSQL之Redis技術視頻教程
  • 燕十八redis視頻教程燕十八redis視頻教程
  • 視頻教程分類
    第十期線上培訓班 澳洲幸运8在哪里开奖