首頁 >頭條 > 正文

PHP基于Redis實現輕量級延遲隊列(多線程)

轉載2020-01-17 17:19:410936
phpStudy Linux 面板(小皮面板)

延遲隊列,顧名思義它是一種帶有延遲功能的消息隊列。 那么,是在什么場景下我才需要這樣的隊列呢?

一、背景

先看看一下業務場景:

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個部分

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

DelayBucket是一組以時間為維度的有序隊列,用來存放所有需要延遲的Job(這里只存放Job Id)。

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

ReadyQueue存放處于Ready狀態的Job(這里只存放JobId),以供消費程序消費。

c882fbf5a572e029727a410b8903e5c.png

消息結構

每個Job必須包含一下幾個屬性:

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

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

delayTime:jod延遲執行的時間,13位時間戳

ttr(time-to-run):Job執行超時時間。

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+

四、架構設計與說明

總體架構

92d38360608cc2fe97a447e3172faa9.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

五、模塊流程圖

消息寫入:

ff3a39383a46ef0ecd570fe0c003b1f.png

timer查找到期消息:

c7d5682d288aa15b1886c6f62f6725b.png

consumer消費流程:

d98aab765eae67b105b8f5e65810ead.png

六、部署

環境依賴:PHP 5.4+ 安裝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了路徑

命令:

php DqHttpServer.php --port 8088

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

f1381af36d0ea1cb1376769a5d54385.png

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

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

56fd5d7611c28356a9a3c43c35df923.png

stop5:注冊topic

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

4b0326ddac4f9350b660186248bc3fb.png

step6:啟動服務進程:

php DqInit.php --port 6789 &

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

9e224a8116e17d52c9193530547c6ef.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內能成功返回請求成功的個數

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

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 ,發現某個系統函數調用是其他的數倍,可能大概率程序存在問題

九、異常處理

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

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

3.redis宕機通知:

115121cd4d1929a75153b85506530de.png

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

十、線上情況

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

主要接入業務:

·訂單10分鐘召回通知

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

·會員過期前3天召回通知

十一、不足與展望

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

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

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

PHP中文網,有大量免費的PHP視頻教程,歡迎大家學習!

本文轉自:https://www.jianshu.com/p/58f10ac42162

php中文網最新課程二維碼
  • 相關標簽:PHP Redis 輕量級 延遲隊列 多線程
  • 本文轉載于:簡書,如有侵犯,請聯系[email protected]刪除
  • 相關文章

    相關視頻


    網友評論

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

    我要評論
  • 專題推薦

    推薦視頻教程
  • PHP零基礎視頻教程PHP零基礎視頻教程
  • PHP技術小知識每日分享(精品)PHP技術小知識每日分享(精品)
  • 《php全棧開發經驗分享》連續4天大型公益直播!《php全棧開發經驗分享》連續4天大型公益直播!
  • php7實戰開發cms內容管理系統php7實戰開發cms內容管理系統
  • 視頻教程分類
    118期四肖中特唯一