基于php和redis實(shí)現(xiàn)的延遲隊(duì)列
來(lái)源：藏色散人 發(fā)布時(shí)間：2019-01-04 14:51:47 閱讀量：1094
基于redis實(shí)現(xiàn)高可用，易拓展，接入方便，生產(chǎn)環(huán)境穩(wěn)定運(yùn)行的延遲隊(duì)列。延遲隊(duì)列，顧名思義它是一種帶有延遲功能的消息隊(duì)列。 那么，是在什么場(chǎng)景下我才需要這樣的隊(duì)列呢？
推薦教程：《redis視頻教程》
一、背景
先看看一下業(yè)務(wù)場(chǎng)景：
1.會(huì)員過(guò)期前3天發(fā)送召回通知
2.訂單支付成功后，5分鐘后檢測(cè)下游環(huán)節(jié)是否都正常，比如用戶購(gòu)買會(huì)員后，各種會(huì)員狀態(tài)是否都設(shè)置成功
3.如何定期檢查處于退款狀態(tài)的訂單是否已經(jīng)退款成功？
4.實(shí)現(xiàn)通知失敗，1，3，5，7分鐘重復(fù)通知，直到對(duì)方回復(fù)？
通常解決以上問(wèn)題，最簡(jiǎn)單直接的辦法就是定時(shí)去掃表。
掃表存在的問(wèn)題是：
1.掃表與數(shù)據(jù)庫(kù)長(zhǎng)時(shí)間連接，在數(shù)量量大的情況容易出現(xiàn)連接異常中斷，需要更多的異常處理，對(duì)程序健壯性要求高
2.在數(shù)據(jù)量大的情況下延時(shí)較高，規(guī)定內(nèi)處理不完，影響業(yè)務(wù)，雖然可以啟動(dòng)多個(gè)進(jìn)程來(lái)處理，這樣會(huì)帶來(lái)額外的維護(hù)成本，不能從根本上解決。
3.每個(gè)業(yè)務(wù)都要維護(hù)一個(gè)自己的掃表邏輯。 當(dāng)業(yè)務(wù)越來(lái)越多時(shí)，發(fā)現(xiàn)掃表部分的邏輯會(huì)重復(fù)開(kāi)發(fā)，但是非常類似
延時(shí)隊(duì)列能對(duì)于上述需求能很好的解決
二、調(diào)研
調(diào)研了市場(chǎng)上一些開(kāi)源的方案，以下：
1.有贊科技：只有原理，沒(méi)有開(kāi)源代碼
2.github個(gè)人的：https://github.com/ouqiang/delay-queue
1 2 3 |
|
3.SchedulerX-阿里開(kāi)源的： 功能很強(qiáng)大，但是運(yùn)維復(fù)雜，依賴組件多，不夠輕量
4.RabbitMQ-延時(shí)任務(wù): 本身沒(méi)有延時(shí)功能，需要借助一特性自己實(shí)現(xiàn)，而且公司沒(méi)有部署這個(gè)隊(duì)列，去單獨(dú)部署一個(gè)這個(gè)來(lái)做延時(shí)隊(duì)列成本有點(diǎn)高，而且還需要專門的運(yùn)維來(lái)維護(hù)，目前團(tuán)隊(duì)不支持
基本以上原因打算自己寫一個(gè)，平常使用php多，項(xiàng)目基本redis的zset結(jié)構(gòu)作為存儲(chǔ)，用php語(yǔ)言實(shí)現(xiàn) ，實(shí)現(xiàn)原理參考了有贊團(tuán)隊(duì)：https://tech.youzan.com/queuing_delay/
整個(gè)延遲隊(duì)列主要有4個(gè)部分：
1.JobPool用來(lái)存放所有Job的元信息。
2.DelayBucket是一組以時(shí)間為維度的有序隊(duì)列，用來(lái)存放所有需要延遲的Job（這里只存放Job Id）。
3.Timer負(fù)責(zé)實(shí)時(shí)掃描各個(gè)Bucket，并將delay時(shí)間大于等于當(dāng)前時(shí)間的Job放入到對(duì)應(yīng)的Ready Queue。
4.ReadyQueue存放處于Ready狀態(tài)的Job（這里只存放JobId），以供消費(fèi)程序消費(fèi)。
消息結(jié)構(gòu) 每個(gè)Job必須包含一下幾個(gè)屬性：
1.topic：Job類型?？梢岳斫獬删唧w的業(yè)務(wù)名稱。
2.id：Job的唯一標(biāo)識(shí)。用來(lái)檢索和刪除指定的Job信息。
3.delayTime：jod延遲執(zhí)行的時(shí)間，13位時(shí)間戳
4.ttr（time-to-run)：Job執(zhí)行超時(shí)時(shí)間。
5.body：Job的內(nèi)容，供消費(fèi)者做具體的業(yè)務(wù)處理，以json格式存儲(chǔ)。
對(duì)于同一類的topic delaytime,ttr一般是固定，job可以在精簡(jiǎn)一下屬性
1.topic：Job類型?？梢岳斫獬删唧w的業(yè)務(wù)名稱
2.id：Job的唯一標(biāo)識(shí)。用來(lái)檢索和刪除指定的Job信息。
3.body：Job的內(nèi)容，供消費(fèi)者做具體的業(yè)務(wù)處理，以json格式存儲(chǔ)。
delaytime,ttr在topicadmin后臺(tái)配置
三、目標(biāo)
輕量級(jí)：有較少的php的拓展就能直接運(yùn)行，不需要引入網(wǎng)絡(luò)框架，比如swoole，workman之類的
穩(wěn)定性：采用master-work架構(gòu)，master不做業(yè)務(wù)處理，只負(fù)責(zé)管理子進(jìn)程，子進(jìn)程異常退出時(shí)自動(dòng)拉起
可用性：
1.支持多實(shí)例部署，每個(gè)實(shí)例無(wú)狀態(tài)，一個(gè)實(shí)例掛掉不影響服務(wù)
2.支持配置多個(gè)redis，一個(gè)redis掛了只影響部分消息
3.業(yè)務(wù)方接入方便，在后臺(tái)只需填寫相關(guān)消息類型和回調(diào)接口
拓展性: 當(dāng)消費(fèi)進(jìn)程存在瓶頸時(shí)，可以配置加大消費(fèi)進(jìn)程數(shù)，當(dāng)寫入存在瓶頸時(shí)，可增加實(shí)例數(shù)寫入性能可線性提高
實(shí)時(shí)性：允許存在一定的時(shí)間誤差。
支持消息刪除：業(yè)務(wù)使用方，可以隨時(shí)刪除指定消息。
消息傳輸可靠性：消息進(jìn)入到延遲隊(duì)列后，保證至少被消費(fèi)一次。
寫入性能：qps>1000+
四、架構(gòu)設(shè)計(jì)與說(shuō)明
總體架構(gòu)
采用master-work架構(gòu)模式，主要包括6個(gè)模塊：
1.dq-mster: 主進(jìn)程，負(fù)責(zé)管理子進(jìn)程的創(chuàng)建，銷毀，回收以及信號(hào)通知
2.dq-server: 負(fù)責(zé)消息寫入，讀取，刪除功能以及維護(hù)redis連接池
3.dq-timer-N: 負(fù)責(zé)從redis的zset結(jié)構(gòu)中掃描到期的消息，并負(fù)責(zé)寫入ready 隊(duì)列，個(gè)數(shù)可配置，一般2個(gè)就行了，因?yàn)橄⒃趜set結(jié)構(gòu)是按時(shí)間有序的
4.dq-consume-N: 負(fù)責(zé)從ready隊(duì)列中讀取消息并通知給對(duì)應(yīng)回調(diào)接口，個(gè)數(shù)可配置
5.dq-redis-checker: 負(fù)責(zé)檢查redis的服務(wù)狀態(tài)，如果redis宕機(jī)，發(fā)送告警郵件
6.dq-http-server: 提供web后臺(tái)界面，用于注冊(cè)topic
五、模塊流程圖
消息寫入:
timer查找到期消息:
consumer消費(fèi)流程:
六、部署
環(huán)境依賴：PHP 5.5+ 安裝sockets，redis，pcntl,pdo_mysql 拓展
ps: 熟悉docker的同學(xué)可以直接用鏡像: shareclz/php7.2.14 里面包含了所需拓展
step1:安裝數(shù)據(jù)庫(kù)用于存儲(chǔ)一些topic以及告警信息
執(zhí)行:
1 |
|
step2:在DqConfg.文件中配置數(shù)據(jù)庫(kù)信息： DqConf::$db
step3: 啟動(dòng)http服務(wù)
在DqConf.php文件中修改php了路徑 $phpBin
命令：
1 |
|
訪問(wèn):http://127.0.0.1:8088,出現(xiàn)配置界面
redis信息格式：host:port:auth 比如 127.0.0.1:6379:12345
step4:配置告信息(比如redis宕機(jī))
step5:注冊(cè)topic
重試標(biāo)記說(shuō)明:
1 2 3 4 5 6 |
|
step6:啟動(dòng)服務(wù)進(jìn)程:
1 |
|
執(zhí)行 ps -ef | grep dq 看到如下信息說(shuō)明啟動(dòng)成功
step7: 寫入數(shù)據(jù)，參考demo.php
step8:查看日志
默認(rèn)日志目錄在項(xiàng)目目錄的logs目錄下，在DqConf.php修改$logPath
1.請(qǐng)求日志：request_ymd.txt
2.通知日志：notify_ymd.txt
3.錯(cuò)誤日志：err_ymd.txt
step9:如果配置文件有改動(dòng)
1.系統(tǒng)會(huì)自動(dòng)檢測(cè)配置文件新，如果有改動(dòng)，會(huì)自動(dòng)退出(沒(méi)有找到較好的熱更新的方案)，需要重啟，可以在crontab里面建個(gè)任務(wù),1分鐘執(zhí)行一次，程序有check_self的判斷
2.優(yōu)雅退出命令: master檢測(cè)偵聽(tīng)了USR2信號(hào)，收到信號(hào)后會(huì)通知所有子進(jìn)程，子進(jìn)程完成當(dāng)前任務(wù)后會(huì)自動(dòng)退出
1 |
|
七、性能測(cè)試
需要安裝pthreads拓展：
測(cè)試原理：使用多線程模擬并發(fā)，在1s內(nèi)能成功返回請(qǐng)求成功的個(gè)數(shù)
1 2 3 4 5 |
|
八、值得一提的性能優(yōu)化點(diǎn)：
1.redis multi命令：將多個(gè)對(duì)redis的操作打包成一個(gè)減少網(wǎng)絡(luò)開(kāi)銷
2.計(jì)數(shù)的操作異步處理，在異步邏輯里面用函數(shù)的static變量來(lái)保存，當(dāng)寫入redis成功后釋放static變量，可以在redis出現(xiàn)異常時(shí)計(jì)數(shù)仍能保持一致，除非進(jìn)程退出
3.內(nèi)存泄露檢測(cè)有必要: 所有的內(nèi)存分配在底層都是調(diào)用了brk或者mmap，只要程序只有大量brk或者mmap的系統(tǒng)調(diào)用，內(nèi)存泄露可能性非常高 ,檢測(cè)命令:
1 |
|
4.檢測(cè)程序的系統(tǒng)調(diào)用情況：strace -c -p pid ，發(fā)現(xiàn)某個(gè)系統(tǒng)函數(shù)調(diào)用是其他的數(shù)倍，可能大概率程序存在問(wèn)題
推薦參考：《Redis命令操作中文手冊(cè)》
九、異常處理
1.如果調(diào)用通知接口在超時(shí)時(shí)間內(nèi)，沒(méi)有收到回復(fù)認(rèn)為通知失敗，系統(tǒng)會(huì)重新把數(shù)據(jù)放入隊(duì)列，重新通知，系統(tǒng)默認(rèn)最大通知10次(可以在Dqconf.php文件中修改$notify_exp_nums)通知間隔為2n+1，比如第一次1分鐘，通知失敗，第二次3分鐘后，直到收到回復(fù)，超出最大通知次數(shù)后系統(tǒng)自動(dòng)丟棄，同時(shí)發(fā)郵件通知
2.線上redis每隔1s持久化一次，存在丟失1s數(shù)據(jù)的情況，出現(xiàn)這種情況可以對(duì)比request_ymd.txt和notify_ymd.txt日志手動(dòng)恢復(fù)過(guò)來(lái)
3.redis宕機(jī)通知:
ps:網(wǎng)絡(luò)抖動(dòng)在所難免，通知接口如果涉及到核心的服務(wù),一定要保證冪等??！
十、線上情況
線上部署了兩個(gè)實(shí)例每個(gè)機(jī)房部一個(gè)，4個(gè)redis共16G內(nèi)存作存儲(chǔ)，服務(wù)穩(wěn)定運(yùn)行數(shù)月，各項(xiàng)指標(biāo)均符合預(yù)期
主要接入業(yè)務(wù):
訂單10分鐘召回通知
調(diào)用接口超時(shí)或者失敗時(shí)做補(bǔ)償
會(huì)員過(guò)期前3天召回通知
十一、不足與展望
1.由于團(tuán)隊(duì)使用的鏡像缺少libevent拓展，所以dq-server基于select模型，并發(fā)高的場(chǎng)景下性能存在瓶頸，后續(xù)可以改為基于libevent事件模型，提升并發(fā)性能
2.timer和consumer目前是采用多進(jìn)程來(lái)做的，這個(gè)粒度感覺(jué)有點(diǎn)粗，可以考慮使用多線程模式，并且支持動(dòng)態(tài)創(chuàng)建線程數(shù)來(lái)提高consumer的性能，最大程度保證消費(fèi)及時(shí)
3.dq-server與redis是同步調(diào)用，這也是性能的瓶頸點(diǎn)，計(jì)劃基于swoole_redis來(lái)異步處理
[更新]
一、測(cè)試網(wǎng)絡(luò)框架切換到swoole和使用異步swoole_redis帶來(lái)的性能改變情況 把dqserver的主要邏輯基于swoole重新寫了一遍，測(cè)試機(jī)(內(nèi)存4G,cpu個(gè)數(shù)4)
啟動(dòng)sever:
1 |
|
壓測(cè):
1 |
|
結(jié)果:
1.原生dq-server: qps 2200
2.基于swoole&swoole_redis: qps 5600
寫入性能提升:2.6倍
引入swoole性能提升比較明顯，不過(guò)目前暫時(shí)不打算把server改為swoole的方式，主要基于以下考慮
1.目前我們線上單個(gè)示例的qps3000，部署了兩個(gè)，6000ps可以滿足我們大部分場(chǎng)景
2.目前對(duì)swoole處于了解的過(guò)程
二、新增隊(duì)列消費(fèi)分優(yōu)先級(jí)（高，中，低3級(jí)），高優(yōu)任務(wù)可以優(yōu)先消費(fèi) 消費(fèi)比例在DqConf::$priorityConfig配置，默認(rèn)按照5：3：2的比例消費(fèi)
13450931319
微信登錄
QQ登錄
微博登錄
售前咨詢
