作者:愛的奇跡,前百度高級工程師葱淳,現(xiàn)供職于微博钝腺,一直做 PHP 相關(guān)的開發(fā)工作。
延遲隊列赞厕,顧名思義它是一種帶有延遲功能的消息隊列艳狐。 那么,是在什么場景下我才需要這樣的隊列呢坑傅?
一僵驰、背景
先看看一下業(yè)務(wù)場景:
1.會員過期前3天發(fā)送召回通知
2.訂單支付成功后,5分鐘后檢測下游環(huán)節(jié)是否都正常唁毒,比如用戶購買會員后蒜茴,各種會員狀態(tài)是否都設(shè)置成功
3.如何定期檢查處于退款狀態(tài)的訂單是否已經(jīng)退款成功?
4.實現(xiàn)通知失敗浆西,1粉私,3,5近零,7分鐘重復(fù)通知诺核,直到對方回復(fù)?
通常解決以上問題久信,最簡單直接的辦法就是定時去掃表窖杀。
掃表存在的問題是:
1.掃表與數(shù)據(jù)庫長時間連接,在數(shù)量量大的情況容易出現(xiàn)連接異常中斷裙士,需要更多的異常處理入客,對程序健壯性要求高
2.在數(shù)據(jù)量大的情況下延時較高,規(guī)定內(nèi)處理不完,影響業(yè)務(wù)桌硫,雖然可以啟動多個進(jìn)程來處理夭咬,這樣會帶來額外的維護(hù)成本,不能從根本上解決铆隘。
3.每個業(yè)務(wù)都要維護(hù)一個自己的掃表邏輯卓舵。 當(dāng)業(yè)務(wù)越來越多時,發(fā)現(xiàn)掃表部分的邏輯會重復(fù)開發(fā)膀钠,但是非常類似
延時隊列能對于上述需求能很好的解決
二掏湾、調(diào)研
調(diào)研了市場上一些開源的方案,以下:
1.有贊科技:只有原理托修,沒有開源代碼
-
2.github個人的:https://github.com/ouqiang/delay-queue
1.基于redis實現(xiàn)忘巧,redis只能配置一個,如果redis掛了整個服務(wù)不可用,可用性差點(diǎn)
2.消費(fèi)端實現(xiàn)的是拉模式睦刃,接入成本大砚嘴,每個項目都得去實現(xiàn)一遍接入代碼
3.在star使用的人數(shù)不多,放在生產(chǎn)環(huán)境涩拙,存在風(fēng)險际长,加之對go語言不了解,出了問題難以維護(hù) 3.SchedulerX-阿里開源的: 功能很強(qiáng)大兴泥,但是運(yùn)維復(fù)雜工育,依賴組件多,不夠輕量
4.RabbitMQ-延時任務(wù): 本身沒有延時功能搓彻,需要借助一特性自己實現(xiàn)如绸,而且公司沒有部署這個隊列,去單獨(dú)部署一個這個來做延時隊列成本有點(diǎn)高旭贬,而且還需要專門的運(yùn)維來維護(hù)怔接,目前團(tuán)隊不支持
基本以上原因打算自己寫一個,平常使用php多稀轨,項目基本redis的zset結(jié)構(gòu)作為存儲扼脐,用php語言實現(xiàn) ,實現(xiàn)原理參考了有贊團(tuán)隊:https://tech.youzan.com/queuing_delay/
整個延遲隊列主要由4個部分
JobPool用來存放所有Job的元信息奋刽。
DelayBucket是一組以時間為維度的有序隊列瓦侮,用來存放所有需要延遲的Job(這里只存放Job Id)。
Timer負(fù)責(zé)實時掃描各個Bucket佣谐,并將delay時間大于等于當(dāng)前時間的Job放入到對應(yīng)的Ready Queue肚吏。
ReadyQueue存放處于Ready狀態(tài)的Job(這里只存放JobId),以供消費(fèi)程序消費(fèi)狭魂。
消息結(jié)構(gòu)
每個Job必須包含一下幾個屬性:
topic:Job類型罚攀∮醵希可以理解成具體的業(yè)務(wù)名稱。
id:Job的唯一標(biāo)識坞生。用來檢索和刪除指定的Job信息。
delayTime:jod延遲執(zhí)行的時間掷伙,13位時間戳
ttr(time-to-run):Job執(zhí)行超時時間是己。
body:Job的內(nèi)容,供消費(fèi)者做具體的業(yè)務(wù)處理任柜,以json格式存儲卒废。
對于同一類的topic delaytime,ttr一般是固定,job可以在精簡一下屬性
1.topic:Job類型宙地∷と希可以理解成具體的業(yè)務(wù)名稱
2.id:Job的唯一標(biāo)識。用來檢索和刪除指定的Job信息宅粥。
3.body:Job的內(nèi)容参袱,供消費(fèi)者做具體的業(yè)務(wù)處理,以json格式存儲秽梅。
delaytime,ttr在topicadmin后臺配置
三抹蚀、目標(biāo)
輕量級:有較少的php的拓展就能直接運(yùn)行,不需要引入網(wǎng)絡(luò)框架企垦,比如swoole环壤,workman之類的
穩(wěn)定性:采用master-work架構(gòu),master不做業(yè)務(wù)處理钞诡,只負(fù)責(zé)管理子進(jìn)程郑现,子進(jìn)程異常退出時自動拉起
可用性:
1.支持多實例部署,每個實例無狀態(tài)荧降,一個實例掛掉不影響服務(wù)
2.支持配置多個redis接箫,一個redis掛了只影響部分消息
3.業(yè)務(wù)方接入方便浩蓉,在后臺只需填寫相關(guān)消息類型和回調(diào)接口
拓展性: 當(dāng)消費(fèi)進(jìn)程存在瓶頸時性锭,可以配置加大消費(fèi)進(jìn)程數(shù),當(dāng)寫入存在瓶頸時划纽,可增加實例數(shù)寫入性能可線性提高
實時性:允許存在一定的時間誤差拗窃。
支持消息刪除:業(yè)務(wù)使用方瞎领,可以隨時刪除指定消息。
消息傳輸可靠性:消息進(jìn)入到延遲隊列后随夸,保證至少被消費(fèi)一次九默。
寫入性能:qps>1000+
四、架構(gòu)設(shè)計與說明
總體架構(gòu)
采用master-work架構(gòu)模式宾毒,主要包括6個模塊:
1.dq-mster: 主進(jìn)程驼修,負(fù)責(zé)管理子進(jìn)程的創(chuàng)建,銷毀,回收以及信號通知
2.dq-server: 負(fù)責(zé)消息寫入乙各,讀取墨礁,刪除功能以及維護(hù)redis連接池
3.dq-timer-N: 負(fù)責(zé)從redis的zset結(jié)構(gòu)中掃描到期的消息,并負(fù)責(zé)寫入ready 隊列耳峦,個數(shù)可配置恩静,一般2個就行了,因為消息在zset結(jié)構(gòu)是按時間有序的
4.dq-consume-N: 負(fù)責(zé)從ready隊列中讀取消息并通知給對應(yīng)回調(diào)接口蹲坷,個數(shù)可配置
5.dq-redis-checker: 負(fù)責(zé)檢查redis的服務(wù)狀態(tài)驶乾,如果redis宕機(jī),發(fā)送告警郵件
6.dq-http-server: 提供web后臺界面循签,用于注冊topic
五级乐、模塊流程圖
消息寫入:
timer查找到期消息:
consumer消費(fèi)流程:
六、部署
環(huán)境依賴:PHP 5.4+ 安裝sockets县匠,redis风科,pcntl,pdo_mysql 拓展
ps: 熟悉docker的同學(xué)可以直接用鏡像: shareclz/php7.2.14 里面包含了所需拓展
step1:安裝數(shù)據(jù)庫用于存儲一些topic以及告警信息
執(zhí)行:
mysql> source dq.sql
step2:在DqConfg.文件中配置數(shù)據(jù)庫信息: DqConf::$db
step3: 啟動http服務(wù)
在DqConf.php文件中修改php了路徑
命令:
php DqHttpServer.php --port 8088
訪問:http://127.0.0.1:8088,出現(xiàn)配置界面
redis信息格式:host:port:auth 比如 127.0.0.1:6379:12345
stop4:配置告信息(比如redis宕機(jī))
stop5:注冊topic
重試標(biāo)記說明:
1.接口返回為空默認(rèn)重試
2.滿足指定返回表達(dá)會重試,res表示返回的json數(shù)組乞旦,比如:
回調(diào)接口返回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:啟動服務(wù)進(jìn)程:
php DqInit.php --port 6789 &
執(zhí)行 ps -ef | grep dq 看到如下信息說明啟動成功
step7: 寫入數(shù)據(jù),參考demo.php
step8:查看日志
默認(rèn)日志目錄在項目目錄的logs目錄下杆查,在DqConf.php修改$logPath
1.請求日志:request_ymd.txt
2.通知日志:notify_ymd.txt
3.錯誤日志:err_ymd.txt
step9:如果配置文件有改動
1.系統(tǒng)會自動檢測配置文件新扮惦,如果有改動,會自動退出(沒有找到較好的熱更新的方案)亲桦,需要重啟崖蜜,可以在crontab里面建個任務(wù),1分鐘執(zhí)行一次,程序有check_self的判斷
2.優(yōu)雅退出命令: master檢測偵聽了USR2信號客峭,收到信號后會通知所有子進(jìn)程豫领,子進(jìn)程完成當(dāng)前任務(wù)后會自動退出
ps -ef | grep dq-master| grep -v grep | head -n 1 | awk '{print $2}' | xargs kill -USR2
七、性能測試
需要安裝pthreads拓展:
測試原理:使用多線程模擬并發(fā)舔琅,在1s內(nèi)能成功返回請求成功的個數(shù)
八等恐、值得一提的性能優(yōu)化點(diǎn):
1.redis multi命令:將多個對redis的操作打包成一個減少網(wǎng)絡(luò)開銷
2.計數(shù)的操作異步處理,在異步邏輯里面用函數(shù)的static變量來保存备蚓,當(dāng)寫入redis成功后釋放static變量课蔬,可以在redis出現(xiàn)異常時計數(shù)仍能保持一致,除非進(jìn)程退出
3.內(nèi)存泄露檢測有必要: 所有的內(nèi)存分配在底層都是調(diào)用了brk或者mmap郊尝,只要程序只有大量brk或者mmap的系統(tǒng)調(diào)用二跋,內(nèi)存泄露可能性非常高 ,檢測命令: strace -c -p pid | grep -P 'mmap| brk'
4.檢測程序的系統(tǒng)調(diào)用情況:strace -c -p pid ,發(fā)現(xiàn)某個系統(tǒng)函數(shù)調(diào)用是其他的數(shù)倍流昏,可能大概率程序存在問題
九扎即、異常處理
1.如果調(diào)用通知接口在超時時間內(nèi)吞获,沒有收到回復(fù)認(rèn)為通知失敗,系統(tǒng)會重新把數(shù)據(jù)放入隊列谚鄙,重新通知各拷,系統(tǒng)默認(rèn)最大通知10次(可以在Dqconf.php文件中修改$notify_exp_nums)通知間隔為2n+1,比如第一次1分鐘闷营,通知失敗撤逢,第二次3分鐘后,直到收到回復(fù)粮坞,超出最大通知次數(shù)后系統(tǒng)自動丟棄,同時發(fā)郵件通知
2.線上redis每隔1s持久化一次初狰,存在丟失1s數(shù)據(jù)的情況莫杈,出現(xiàn)這種情況可以對比request_ymd.txt和notify_ymd.txt日志手動恢復(fù)過來
3.redis宕機(jī)通知:
ps:網(wǎng)絡(luò)抖動在所難免,通知接口如果涉及到核心的服務(wù),一定要保證冪等I萑搿筝闹!
十、線上情況
線上部署了兩個實例每個機(jī)房部一個腥光,4個redis共16G內(nèi)存作存儲关顷,服務(wù)穩(wěn)定運(yùn)行數(shù)月,各項指標(biāo)均符合預(yù)期
主要接入業(yè)務(wù):
訂單10分鐘召回通知
調(diào)用接口超時或者失敗時做補(bǔ)償
會員過期前3天召回通知
十一武福、不足與展望
1.由于團(tuán)隊使用的鏡像缺少libevent拓展议双,所以dq-server基于select模型,并發(fā)高的場景下性能存在瓶頸捉片,后續(xù)可以改為基于libevent事件模型平痰,提升并發(fā)性能
2.timer和consumer目前是采用多進(jìn)程來做的,這個粒度感覺有點(diǎn)粗伍纫,可以考慮使用多線程模式宗雇,并且支持動態(tài)創(chuàng)建線程數(shù)來提高consumer的性能,最大程度保證消費(fèi)及時
3.dq-server與redis是同步調(diào)用莹规,這也是性能的瓶頸點(diǎn)赔蒲,計劃基于swoole_redis來異步處理
十二、參考
https://www.cnblogs.com/peachyy/p/7398430.html