一、背景:
為了解決程式面對一些實時性不高,但是量較大的任務,而帶來服務器的高CPU,高負載的情況,我們推出補償(重試)任務,
就是先把這些任務落庫,然后啟動定時任務定時定量的查詢DB的資料,做業務處理,
二、場景:
發送訊息,同步資料,異步呼叫,介面失敗補償等;
三、分析:
1、由于定時任務需要一直掃描任務表,那我們的任務表肯定不能無限增大,所以我們設計兩張表:任務表 和 歸檔表(歷史表),
任務表:存放待執行的任務,也包括執行失敗需要重試的,
歸檔表:存放已經到達終態的任務,比如:成功,失敗,重試到最大次數依然失敗的,
2、不同的場景,每次從DB撈的資料量不一樣,重試間隔也不一樣,且資料量和間隔時間都是可動態配置的,
3、對于場景的新增和洗掉要友好的進行擴展,
四、擼核心代碼(以發送短信為例):
1、DB
CREATE TABLE `retry_task` (
`task_id` varchar(128) NOT NULL COMMENT '主鍵id',
`gmt_create` timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) COMMENT '創建時間',
`gmt_modified` timestamp(6) NOT NULL DEFAULT '0000-00-00 00:00:00.000000' COMMENT '修改時間',
`status` varchar(64) NOT NULL COMMENT '補償任務狀態,為INIT,PROCESSING',
`biz_id` varchar(64) NOT NULL COMMENT '業務號',
`biz_type` varchar(64) NOT NULL COMMENT '業務型別',
`biz_context` varchar(20000) NOT NULL COMMENT '業務資料',
`retry_no` varchar(32) NOT NULL COMMENT '重試次數',
`schedule_time` timestamp(6) NOT NULL DEFAULT '0000-00-00 00:00:00.000000' COMMENT '下一次調度執行時間',
`memo` varchar(1024) DEFAULT NULL COMMENT '備注',
PRIMARY KEY (`task_id`),
UNIQUE KEY `uk_biz_type_biz_id` (`biz_type`,`biz_id`)
KEY `idx_biz_type_schedule_time` (`biz_type`,`schedule_time`,`task_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='重試任務';
CREATE TABLE `retry_task_history` (
`task_id` varchar(128) NOT NULL COMMENT '主鍵id',
`gmt_create` timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) COMMENT '創建時間',
`gmt_modified` timestamp(6) NOT NULL DEFAULT '0000-00-00 00:00:00.000000' COMMENT '修改時間',
`status` varchar(64) NOT NULL COMMENT '補償任務狀態,為SUCCESS,FAILED或ABORT',
`biz_id` varchar(64) NOT NULL COMMENT '業務號',
`biz_type` varchar(64) NOT NULL COMMENT '業務型別',
`biz_context` varchar(20000) NOT NULL COMMENT '業務資料',
`retry_no` varchar(32) NOT NULL COMMENT '重試次數',
`schedule_time` timestamp(6) NOT NULL DEFAULT '0000-00-00 00:00:00.000000' COMMENT '下一次調度執行時間',
`memo` varchar(1024) NOT NULL COMMENT '備注',
PRIMARY KEY (`task_id`),
UNIQUE KEY `uk_biz_type_biz_id` (`biz_type`,`biz_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='重試任務歷史表';
2、發送短信的具體業務 SendSmsServiceImpl

3、發送短信的執行器 SendSmsTaskExecutor,繼承 RetryTaskExecutor


4、核心配置類 RetryTaskConfig,主要用于獲取場景,獲取重試間隔,獲取撈取資料量大小,以及獲取和場景對應的執行器,并把這些資料和場景關聯在一起,保存到Map中,



5、核心調度策略類 ScheduleStrategy,主要用于決議時間間隔,計算重試次數,下次重試時間等

6、核心重試任務管理類 RetryTaskManagerImpl,管理重試任務執行器的注冊,重試任務的創建,重試任務的處理等,





關于重試任務的具體處理邏輯,可看下圖

這里處理的邏輯其實很簡單,只用到了INIT、SUCCESS、FAILED三種狀態,如果你有興趣,可以完善一下,加上 ABORT 和 RETRY 狀態
7、調度任務 RetryTaskSchedule,我這里是為了測驗,每5s執行一次


8、測驗類 RetryTaskController ,SendSmsManagerImpl


9、大致思路已經提供,需要具體詳細的代碼的話,可以私信我,我稍后也會同步到gitlab中
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/242851.html
標籤:其他

