延遲佇列,顧名思義它是一種帶有延遲功能的訊息佇列。 那麼,是在什麼場景下我才需要這樣的佇列呢?
一、背景
先看看一下業務場景:
- 1.會員過期前3天傳送召回通知
- 2.訂單支付成功後,5分鐘後檢測下游環節是否都正常,比如使用者購買會員後,各種會員狀態是否都設定成功
- 3.如何定期檢查處於退款狀態的訂單是否已經退款成功?
- 4.實現通知失敗,1,3,5,7分鐘重複通知,直到對方回覆?
通常解決以上問題,最簡單直接的辦法就是定時去掃表。
掃表存在的問題是:
- 1.掃表與資料庫長時間連線,在數量量大的情況容易出現連線異常中斷,需要更多的異常處理,對程式健壯性要求高
- 2.在資料量大的情況下延時較高,規定內處理不完,影響業務,雖然可以啟動多個程式來處理,這樣會帶來額外的維護成本,不能從根本上解決。
- 3.每個業務都要維護一個自己的掃表邏輯。 當業務越來越多時,發現掃表部分的邏輯會重複開發,但是非常類似
延時佇列能對於上述需求能很好的解決
二、調研
調研了市場上一些開源的方案,以下:
-
1.有贊科技:只有原理,沒有開原始碼
-
2.github個人的:github.com/ouqiang/del…
1.基於redis實現,redis只能配置一個,如果redis掛了整個服務不可用,可用性差點 2.消費端實現的是拉模式,接入成本大,每個專案都得去實現一遍接入程式碼 3.在star使用的人數不多,放在生產環境,存在風險,加之對go語言不瞭解,出了問題難以維護 複製程式碼
-
3.SchedulerX-阿里開源的: 功能很強大,但是運維複雜,依賴元件多,不夠輕量
-
4.RabbitMQ-延時任務: 本身沒有延時功能,需要藉助一特性自己實現,而且公司沒有部署這個佇列,去單獨部署一個這個來做延時佇列成本有點高,而且還需要專門的運維來維護,目前團隊不支援
基本以上原因打算自己寫一個,平常使用php多,專案基本redis的zset結構作為儲存,用php語言實現 ,實現原理參考了有贊團隊:tech.youzan.com/queuing_del…
三、目標
- 輕量級:有較少的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
五、部署
環境依賴:PHP 5.4+ 安裝sockets,redis,pcntl,pdo_mysql 擴充
step1:安裝資料庫用於儲存一些topic以及告警資訊
create database dq;
#存放告警資訊
CREATE TABLE `dq_alert` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`host` varchar(255) NOT NULL DEFAULT '',
`port` int(11) NOT NULL DEFAULT '0',
`user` varchar(255) NOT NULL DEFAULT '',
`pwd` varchar(255) NOT NULL DEFAULT '',
`ext` varchar(2048) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
#存放redis資訊
CREATE TABLE `dq_redis` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`t_name` varchar(200) NOT NULL DEFAULT '',
`t_content` varchar(2048) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8;
#儲存註冊資訊
CREATE TABLE `dq_topic` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`t_name` varchar(1024) NOT NULL DEFAULT '',
`delay` int(11) NOT NULL DEFAULT '0',
`callback` varchar(1024) NOT NULL DEFAULT '',
`timeout` int(11) NOT NULL DEFAULT '3000',
`email` varchar(1024) NOT NULL DEFAULT '',
`topic` varchar(255) NOT NULL DEFAULT '',
`createor` varchar(1024) NOT NULL DEFAULT '',
`status` tinyint(4) NOT NULL DEFAULT '1',
`method` varchar(32) NOT NULL DEFAULT 'GET',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
複製程式碼
step2:在DqConfg.檔案中配置資料庫資訊: DqConf::$db
step3: 啟動http服務
在DqConf.php檔案中修改php了路徑 $logPath
命令:
php DqHttpServer.php --port 8088
訪問:http://127.0.0.1:8088,出現配置介面
redis資訊格式:host:post:auth 比如 127.0.0.1:6379:12345stop4:啟動服務程式:
php DqInit.php --port 6789 看到如下資訊說明啟動成功
stop5:配置告資訊(比如redis當機)
stop6:註冊topic
step7: 寫入資料,在專案根目錄下新建test.php檔案寫入
<?php
include_once 'DqLoader.php';
date_default_timezone_set("PRC");
//可配置多個
$server=array(
'127.0.0.1:6789',
);
$dqClient = new DqClient();
$dqClient->addServer($server);
$topic ='order_openvip_checker'; //topic在後臺註冊
$id = uniqid();
$data=array(
'id'=>$id,
'body'=>array(
'a'=>1,
'b'=>2,
'c'=>3,
'ext'=>str_repeat('a',64),
),
//可選,設定後以這個通知時間為準,預設延時時間在註冊topic的時候指定
'fix_time'=>date('Y-m-d 23:50:50'),
);
//新增
$boolRet = $dqClient->add($topic, $data);
echo 'add耗時:'.(msectime() - $time)."ms\n";
//查詢
$time = msectime();
$result = $dqClient->get($topic, $id);
echo 'get耗時:'.(msectime() - $time)."ms\n";
//刪除
$time = msectime();
$boolRet = $dqClient->del($topic,$id);
echo 'del耗時:'.(msectime() - $time)."ms\n";
複製程式碼
執行php test.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 'mmap| brk'
- 4.檢測程式的系統呼叫情況:strace -c -p pid ,發現某個系統函式呼叫是其他的數倍,可能大概率程式存在問題
八、異常處理
如果呼叫通知介面在超時時間內,沒有收到回覆認為通知失敗,系統會重新把資料放入佇列,重新通知,系統預設最大通知10次(可以在Dqconf.php檔案中修改$notify_exp_nums)通知間隔為2n+1,比如第一次1分鐘,通知失敗,第二次3分鐘後,直到收到回覆,超出最大通知次數後系統自動丟棄,同時發郵件通知
ps:網路抖動在所難免,通知介面如果涉及到核心的服務,一定要保證冪等!!
九、線上情況
線上部署了兩個例項每個機房部一個,4個redis作儲存,服務穩定執行數月,各項指標均符合預期
主要接入業務:
- 訂單10分鐘召回通知
- 介面超時或者失敗補償
專案地址: github.com/chenlinzhon…