作者：齐海智

在 618 大促的技术战场上，每一行代码、每一个配置都影响着一线的实实在在的业务。一次看似平常的发版，却意外暴露了我们系统中的定时任务管理短板，这促使我们深入剖析分布式任务调度中异常重试机制的技术细节，并最终将其转化为守护系统稳定性的坚固防线。​

一、异常事件回溯：隐藏在发版背后的定时炸弹​

发版次日，业务部门反馈商家未收到门店收货明细邮件，导致门店收货业务收到影响。技术团队迅速启动应急流程，通过全链路日志追踪和系统状态分析，发现了问题的根源是：发版过程中，由于服务重启，中断了定时任务进程，正在执行的邮件发送任务被意外终止。而该任务在管理平台上并未配置任何重试策略，业务代码上也没有进行相关的检测和重试，这就导致任务失败后无法自动恢复执行，也未被及时感知到，进而引发业务阻断。​

为解决燃眉之急，研发人员立即登录任务管理平台，手工触发邮件发送任务，确保业务及时恢复。但这次事件给我们敲响了警钟：在分布式任务调度场景下，面对网络抖动、进程异常终止等场景，异常重试机制是保障业务可靠性的关键。​

二、重试策略设计：从理论到代码的深度解析​

2.1 验证EasyJob的重试策略

在复盘问题的过程中，我们发现了EasyJob分布式任务是具有重试策略的，只是默认不开启，而不是默认开启。





该策略以三个核心参数为基础：首次重试间隔时间 F、重试间隔乘数 M 和最大重试次数 C。

通过这三个参数的组合，我们可以灵活控制任务重试节奏，平衡系统负载与任务恢复效率。​

例如：配置t=10s, M=2, C=10，则间隔时间依次是：

验证日志：

21:45:29.990 [main-schedule-worker-pool-1-thread-1] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:45:40.204 [main-schedule-worker-pool-1-thread-2] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:46:00.674 [main-schedule-worker-pool-1-thread-3] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:46:41.749 [main-schedule-worker-pool-1-thread-4] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:48:02.398 [main-schedule-worker-pool-1-thread-5] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:50:43.008 [main-schedule-worker-pool-1-thread-1] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务

与上面计算的一致。

验证方案：

1、实现接口：com.wangyin.schedule.client.job.ScheduleFlowTask，并设置任务返回失败：





2、创建CRON触发器





3、设置自动重试参数





4、暂停任务并手工触发一次



2.2 实现一个简单的重试策略

根据上述策略，简单实现了一个灵活可配置的任务重试机制。

public class TaskRetryExecutor {
    @Getter
    private final ScheduledExecutorService executor = newScheduledThreadPool(10);
    private final long firstRetryInterval;
    private final int intervalMultiplier;
    private final int maxRetryCount;

    public TaskRetryExecutor(long firstRetryInterval, int intervalMultiplier, int maxRetryCount) {
        this.firstRetryInterval = firstRetryInterval;
        this.intervalMultiplier = intervalMultiplier;
        this.maxRetryCount = maxRetryCount;
    }

    public void submitRetryableTask(Runnable task) {
        executeWithRetry(task, 1);
    }

    private void executeWithRetry(Runnable task, int currentRetryCount) {
        executor.schedule(() -> {
            try {
                task.run();
                log.info("任务在第{}次尝试时成功执行", currentRetryCount);
            } catch (Exception e) {
                log.error("任务在第{}次尝试时执行失败", currentRetryCount, e);
                if (currentRetryCount <= maxRetryCount) {
                    long delay = calculateRetryDelay(currentRetryCount);
                    log.info("计划在{}毫秒后进行第{}次重试", delay, currentRetryCount);
                    executeWithRetry(task, currentRetryCount + 1);
                } else {
                    log.error("超过最大重试次数。任务执行最终失败。");
                }
            }
        }, currentRetryCount == 1 ? 0 : calculateRetryDelay(currentRetryCount), TimeUnit.MILLISECONDS);
    }

    public long calculateRetryDelay(int retryCount) {
        if (retryCount == 1) {
            return firstRetryInterval;
        } else if (retryCount > 1 && retryCount <= maxRetryCount) {
            long previousDelay = calculateRetryDelay(retryCount - 1);
            return previousDelay * intervalMultiplier;
        }
        return -1; // 超出最大重试次数，返回错误标识
    }
}

​在上述代码中：

1.TaskRetryExecutor类封装了任务重试的核心逻辑。构造函数接收三个关键参数：firstRetryInterval、intervalMultiplier和maxRetryCount，用于配置重试策略，对应于EasyJob的F、M、C参数。

2.submitRetryableTask方法接收一个可执行任务，并启动重试流程。它调用executeWithRetry方法，初始重试次数为1。

3.executeWithRetry方法是重试逻辑的核心。它使用ScheduledExecutorService来调度任务执行：

◦如果任务执行成功，记录成功日志。

◦•如果任务执行失败且未超过最大重试次数，计算下一次重试的延迟时间，并递归调用自身进行重试。

◦•如果超过最大重试次数，记录最终失败日志。

4.calculateRetryDelay方法实现了重试间隔的计算规则：

◦第一次重试使用firstRetryInterval。

◦之后的重试间隔是前一次间隔乘以intervalMultiplier。

◦如果超出最大重试次数，返回-1表示错误。

通过这种设计，我们实现了一个可复用、可配置的任务重试机制。它能够根据配置的参数自动调整重试间隔，在任务失败时进行有策略的重试，同时避免无限重试导致的资源浪费。

详细代码可在以下Git仓库中找到：mailto:git@coding.jd.com:newJavaEngineerOrientation/TaskRetryStrategies.git

2.3 重试策略的理论分析

2.3.1 EasyJob对乘数和最大重试次数的限制

在对EasyJob也进行了重试的验证中发现：

1.每次重做的乘数取值范围是[1,8]，可以是具有一位小数位的浮点数，比如3.5，

2.最多重做次数是[1,16]间的整数，第一次重试的间隔没有限制，单位是秒。



2.3.2 梯度分析

通过上面的验证和重试相关概念的定义，可以得到：第n次重试的间隔时间=第一次间隔时间*乘数^(n-1)，即：

其中：



对乘数M的梯度：

对重试次数n的梯度：



详细推导： http://xingyun.jd.com/codingRoot/newJavaEngineerOrientation/T...

从下图可以看出，重试次数n较大时（比如8），乘数 M 的细微变化都会导致，任务的间隔时间发生剧烈变化，因此n超过8之后，M基本不可调。



同样的，从下图可以看到，乘数M较大时（比如4），n的细微变化也会导致任务的间隔时间爆发式的增加。



1、乘数在1.5-4 的合理性

过小乘数 (<1.5) 的问题：

当乘数 = 1.2，重试 10 次的间隔时间是：1次:1, 2次:1.2, 3次:1.44, ..., 10次:5.16，

10 次重试总间隔仅 5 倍，接近固定间隔，可能导致 "惊群效应"（大量请求同时重试）。

过大乘数 (>4) 的问题

当乘数 = 8，重试 5 次的间隔时间：1次:1, 2次:8, 3次:64, 4次:512, 5次:4096

5 次重试后间隔已超 1 小时（假设初始间隔时间是最小的1s，4096s>1小时），可能导致请求长时间等待，用户体验差。

因此，乘数 = 1.5-4 在 "退避效率" 和 "资源消耗" 间取得平衡，一般取乘数= 2 （标准指数退避）。

行业实践：AWS SDK 默认乘数 = 2，Google gRPC 重试策略推荐乘数 = 1.5-3，多数 HTTP 客户端库 (如 requests) 默认乘数 = 2。

2、最大重试次数3-10的合理性

假设单次重试成功概率为P（比如网络/服务临时故障，重试成功概率通常较高），重试 n次至少成功 1 次的概率为：



当 p=0.5，（单次重试 50% 成功概率）：

n=3 时，成功概率 =1−(0.5)^3=87.5%

n=5 时，成功概率 =1−(0.5)^5=96.875%

n=10 时，成功概率 =1−(0.5)^10≈99.9%

实际场景中，临时故障的单次成功概率远高于 50% （比如网络抖动重试成功概率可能达 80%）

若 p=0.8，n=3时成功概率已达 1−0.2^3=99.2%几乎覆盖所有临时故障。

因此，3 - 10 次重试，能以极高概率（99%+）覆盖“临时故障”场景，再增加次数对成功概率提升极有限（边际效应递减）。

因为已知的任务延迟时间的公式是：

n从1到C进行累加得到总耗时:

，

根据等比数列求和公式可以得到：



令 M=2（常用乘数），F=1 秒（最小可能值）：

n=3时，T=（2^3-1）/（2-1）=7秒

n=5时，T=(2^5-1)/(2-1)=31秒

n=10时，T=2^10-1=1023秒≈17分钟

n=13时，T=2^13-1≈2.3小时

n=15时，T=2^15-1≈9.1小时

当n超过10后，每次增加都会导致总耗时急剧增长，很容易超过业务的容忍上限（具体业务具体分析），也可能因为重试过多，导致被调用的系统压力增加，甚至造成系统崩溃。

故：3 - 10 次重试可将总耗时控制在“业务可接受范围”（几秒到十几分钟），同时避免资源过载。

行业实践：Kafka 消费者重试：默认 10 次、Redis 客户端重试：默认 5 次、Hadoop 任务重试：默认 3-5 次、RFC 建议：RFC 6582（HTTP 重试）建议：3-5 次重试。

3、最佳实践速查表

三、经验沉淀：异常重试机制的设计原则​

通过这次实践和对行业方案的研究，我们总结出异常重试机制设计的四大核心原则：​

1.动态适应性原则：重试策略应支持参数化配置，根据业务场景和系统负载动态调整重试间隔和次数，避免 “一刀切” 的重试策略对系统造成冲击。​

2.幂等性保障原则：确保任务在多次重试过程中不会产生重复数据或副作用，通过唯一标识、状态机等技术手段，实现任务的幂等执行。​

3.故障隔离原则：将重试逻辑与业务逻辑分离，通过消息队列、异步调度等方式，降低重试操作对主线程的影响，避免因重试失败导致系统整体崩溃。​

4.可观测性原则：建立完善的监控和告警体系，实时追踪任务重试状态，在达到最大重试次数时及时发出告警，便于运维人员快速定位和解决问题。​

四、结语：以技术沉淀筑牢大促防线​

这次线上异常事件，犹如一面镜子，让我们清晰地看到了系统中的潜在风险，也为我们提供了一次宝贵的技术提升机会。通过对异常重试机制的深入研究和实践，我们不仅解决了当前问题，更将这些经验转化为团队的技术资产。在未来的 618 大促及其他关键业务场景中，我们将以更完善的技术方案、更严谨的设计原则，守护系统的稳定运行，为业务发展提供坚实的技术保障。

流量统计功能文档

仓库地址:https://gitee.com/teanary/teanary_service

目录

• 功能概述
• 功能特性
• 技术架构
• 配置说明
• 使用方法
• 数据管理
• 常见问题

功能概述

流量统计功能用于统计网站前台的访问数据，包括真人访问和爬虫访问。系统会自动区分访问者类型，并记录详细的访问信息，帮助管理员了解网站的访问情况。

主要功能

• ✅ 自动统计前台访问流量
• ✅ 区分真人访问和爬虫访问
• ✅ 识别爬虫来源（Google、Bing、Baidu等）
• ✅ 缓存数据，批量写入数据库（每5分钟）
• ✅ 自动清理过期数据（默认保留90天）
• ✅ 提供统计看板和详细列表页面

功能特性

1. 智能过滤

系统会自动排除以下请求：

• ❌ 管理后台（/manager/*）
• ❌ 个人中心（/user/*）
• ❌ API 路由（/api/*）
• ❌ 静态资源（.css, .js, .jpg, .png 等）
• ❌ 非 GET 请求

2. 爬虫识别

系统能够识别以下类型的爬虫：

搜索引擎爬虫：

• Google (Googlebot)
• Bing (Bingbot)
• Baidu (Baiduspider)
• Yandex (Yandexbot)
• Yahoo (Slurp)
• DuckDuckGo (Duckduckbot)
• Sogou (Sogou)

社交媒体爬虫：

• Facebook (Facebookexternalhit)
• Twitter (Twitterbot)
• LinkedIn (Linkedinbot)
• Pinterest (Pinterestbot)

其他爬虫：

• Semrush (Semrushbot)
• Ahrefs (Ahrefsbot)
• Majestic (Mj12bot)
• Dotbot
• 以及其他通用爬虫（bot、crawler、spider等）

3. 数据记录

每条流量记录包含以下信息：

• 路径 (path): 访问的页面路径
• 方法 (method): HTTP 方法（通常为 GET）
• IP 地址 (ip): 访问者的 IP 地址
• 用户代理 (user_agent): 浏览器或爬虫的用户代理字符串
• 来源页面 (referer): 来源页面的 URL
• 语言 (locale): 访问时使用的语言代码
• 是否爬虫 (is_bot): 是否为爬虫访问
• 爬虫来源 (spider_source): 爬虫的具体来源（如 google、bing 等）
• 访问次数 (count): 同一分钟内相同路径的访问次数
• 统计时间 (stat_date): 统计日期（精确到分钟）

技术架构

数据流程

用户访问 → TrackTraffic 中间件 → 缓存数据 → 批量写入队列 → 数据库

核心组件

1. 中间件 (TrackTraffic)

   • 位置：app/Http/Middleware/TrackTraffic.php
   • 功能：拦截请求，记录流量数据到缓存

2. 批量写入任务 (BatchWriteTrafficStatsJob)

   • 位置：app/Jobs/BatchWriteTrafficStatsJob.php
   • 功能：每5分钟批量将缓存数据写入数据库

3. 数据清理命令 (CleanOldTrafficStats)

   • 位置：app/Console/Commands/CleanOldTrafficStats.php
   • 功能：清理超过指定天数的历史数据

4. 数据模型 (TrafficStatistic)

   • 位置：app/Models/TrafficStatistic.php
   • 功能：定义数据结构和查询方法

5. 管理界面

   • 统计看板：app/Filament/Manager/Pages/TrafficStatistics.php
   • 详细列表：app/Filament/Manager/Resources/TrafficStatisticResource.php

缓存机制

• 使用 Laravel Cache 存储临时流量数据
• 缓存键格式：traffic:queue:Y-m-d-H-i
• 缓存过期时间：1小时
• 每5分钟批量写入一次数据库

配置说明

1. 中间件注册

中间件已在 routes/web.php 中注册：

Route::prefix('{locale}')->middleware([
    SetLocaleAndCurrency::class, 
    \App\Http\Middleware\TrackTraffic::class
])->group(function () {
    // 前台路由
});

2. 定时任务配置

在 routes/console.php 中已配置：

// 流量统计批量写入任务（每5分钟执行一次）
Schedule::command('app:batch-write-traffic-stats --queue')
    ->everyFiveMinutes()
    ->withoutOverlapping()
    ->runInBackground();

// 流量统计数据清理任务（每天凌晨2点执行，清理90天前的数据）
Schedule::command('app:clean-old-traffic-stats')
    ->dailyAt('02:00')
    ->withoutOverlapping();

3. 数据库表结构

表名：traffic_statistics

主要字段：

• id: 主键（雪花ID）
• path: 访问路径（索引）
• method: HTTP 方法（索引）
• ip: IP 地址（索引）
• user_agent: 用户代理
• referer: 来源页面
• locale: 语言代码（索引）
• is_bot: 是否为爬虫（索引）
• spider_source: 爬虫来源（索引）
• count: 访问次数
• stat_date: 统计时间（索引，精确到分钟）

使用方法

1. 查看统计看板

1. 登录管理后台
2. 导航到 统计 → 流量统计看板

3. 可以查看：

   • 总访问量、页面浏览量、独立IP、独立页面
   • 真人访问和爬虫访问的对比
   • 热门页面 Top 20

4. 支持筛选：

   • 日期范围：今天、昨天、最近7天、最近30天、最近90天
   • 访问者类型：全部、真人访问、爬虫访问

2. 查看详细列表

1. 登录管理后台
2. 导航到 统计 → 流量明细
3. 可以查看每条访问记录的详细信息

4. 支持筛选：

   • 访问类型（真人/爬虫）
   • 爬虫来源
   • 日期范围

3. 手动触发批量写入

如果需要立即将缓存数据写入数据库，可以执行：

php artisan app:batch-write-traffic-stats

4. 手动清理数据

清理超过指定天数的数据：

# 清理90天前的数据（默认）
php artisan app:clean-old-traffic-stats

# 清理30天前的数据
php artisan app:clean-old-traffic-stats --days=30

# 清理180天前的数据
php artisan app:clean-old-traffic-stats --days=180

数据管理

数据保留策略

• 默认保留时间：90天
• 清理时间：每天凌晨2点自动执行
• 清理方式：分批删除，每批1000条记录

数据统计方法

获取指定时间范围内的统计数据

use App\Models\TrafficStatistic;
use Illuminate\Support\Carbon;

// 获取最近7天的所有数据
$startDate = Carbon::today()->subDays(6);
$endDate = Carbon::today()->endOfDay();
$stats = TrafficStatistic::getStatsByDateRange($startDate, $endDate);

// 只获取真人访问数据
$humanStats = TrafficStatistic::getStatsByDateRange($startDate, $endDate, false);

// 只获取爬虫访问数据
$botStats = TrafficStatistic::getStatsByDateRange($startDate, $endDate, true);

获取热门页面

// 获取最近7天的热门页面 Top 10
$topPages = TrafficStatistic::getTopPages($startDate, $endDate, 10);

// 只获取真人访问的热门页面
$topHumanPages = TrafficStatistic::getTopPages($startDate, $endDate, 10, false);

// 只获取爬虫访问的热门页面
$topBotPages = TrafficStatistic::getTopPages($startDate, $endDate, 10, true);

常见问题

Q1: 为什么有些访问没有被统计？

A: 系统会自动排除以下请求：

• 管理后台和个人中心的访问
• API 路由
• 静态资源文件
• 非 GET 请求

如果您的访问路径符合以上条件，将不会被统计。

Q2: 数据多久写入一次数据库？

A: 系统每5分钟自动批量写入一次。如果需要立即写入，可以手动执行 php artisan app:batch-write-traffic-stats 命令。

Q3: 如何修改数据保留时间？

A: 有两种方式：

1. 修改定时任务：编辑 routes/console.php，修改 --days 参数
2. 手动执行：执行 php artisan app:clean-old-traffic-stats --days=天数

Q4: 爬虫识别不准确怎么办？

A: 可以修改 app/Http/Middleware/TrackTraffic.php 中的 isBot() 和 getSpiderSource() 方法，添加或修改爬虫识别规则。

Q5: 如何查看缓存中的数据？

A: 可以使用 Laravel Tinker：

php artisan tinker

然后执行：

// 查看某个时间点的队列
Cache::get('traffic:queue:2026-01-17-14-30');

// 查看所有流量相关的缓存键（需要 Redis）
Redis::keys('traffic:*');

Q6: 数据量很大，会影响性能吗？

A: 系统采用了以下优化措施：

• 使用缓存暂存数据，减少数据库写入频率
• 批量写入，每5分钟写入一次
• 使用索引优化查询性能
• 自动清理过期数据，控制数据量

如果数据量仍然很大，可以考虑：

• 缩短数据保留时间
• 增加批量写入频率
• 优化数据库索引

Q7: 如何禁用流量统计？

A: 从 routes/web.php 中移除 TrackTraffic::class 中间件即可。

Q8: 可以统计其他路径吗？

A: 可以修改 app/Http/Middleware/TrackTraffic.php 中的 shouldTrack() 方法，调整过滤规则。

相关文件

• 中间件：app/Http/Middleware/TrackTraffic.php
• 批量写入任务：app/Jobs/BatchWriteTrafficStatsJob.php
• 清理命令：app/Console/Commands/CleanOldTrafficStats.php
• 数据模型：app/Models/TrafficStatistic.php
• 统计看板：app/Filament/Manager/Pages/TrafficStatistics.php
• 详细列表：app/Filament/Manager/Resources/TrafficStatisticResource.php
• 数据库迁移：database/migrations/2026_01_17_204550_create_traffic_statistics_table.php

更新日志

2026-01-17

• ✅ 初始版本发布
• ✅ 支持真人/爬虫区分
• ✅ 支持爬虫来源识别
• ✅ 自动批量写入和清理

文档版本：1.0
最后更新：2026-01-17