PHP基於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個部分

JobPool用來存放所有Job的元資訊。

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

Timer負責即時掃描各個Bucket，並將delay時間大於等於目前時間的Job放入對應的Ready Queue。

ReadyQueue存放處於Ready狀態的Job（這裡只存放JobId），以供消費性消費。

訊息結構

每個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

四、架構設計與說明

整體架構

采用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.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,出现配置界面

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

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

stop5:注册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内能成功返回请求成功的个数

八、值得一提的性能优化点：

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宕機通知:

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

十、線上情況

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

主要接入業務:

·訂單10分鐘召回通知

·呼叫介面逾時或失敗時做補償

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

1不足與展望

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

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

3.dq-server與redis是同步調用，這也是效能的瓶頸點，計畫基於swoole_redis來非同步處理。

PHP中文網，有大量免費的PHP影片教學，歡迎大家學習！

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