114 lines
5.6 KiB
Markdown
114 lines
5.6 KiB
Markdown
开个定时任务不停扫数据库，未检测的 快到期删除的，全部扫出来推送给注册任务队列；
|
||
|
||
注册检测：筛选出可以注册的，这个完成后，不管成功失败，返会标准化结果给 controller，告诉他，这个流程我走完了，如果是外部原因导致未能出结果就失败的，controller 会重新投入注册检测，更新数据库，如果是成功的，把对应的状态更新数据库，跟新注册状态；
|
||
|
||
controller 收到返回注册完成后， 以标准化格式下一步任务队列里面 ，等worker 来啦取，
|
||
worker 只负责去controller 啦取的任务，处理任务，根据任务标准标识，安排对于的函数处理，所以woker只复制啦和跑，我没任务了，我很有空，我就去controller 获取任务，只要你给，我就跑，跑完返回结果给你；
|
||
controller 在收到worker的啦取请求后，按后台勾选的配置任务队列，按顺序返回给woker，不是随便返回
|
||
controller 返回任务时，要同时完成认领
|
||
也就是：
|
||
标记该 task 已分配给某个 worker
|
||
进入 running 状态
|
||
设置超时 TTL
|
||
超时未回传则回收重投
|
||
否则会出现：
|
||
worker 拿了任务挂了
|
||
controller 以为还在跑
|
||
任务永远丢了
|
||
|
||
|
||
xx检测：当前 xx 步骤执行并返回判定结果，这个完成后，不管成功失败，返会标准化结果给controller，告诉他，这个xx流程我走完了，如果是外部原因导致失败的，还没有出结果的，非业务判定不通过被跑到为黑名单的，controller 会重新投入当前xx任务队列，如果名中黑名单，直接跟新黑名单状态，不在分发到后面所有步骤，更新数据库，如果是成功的，跟新当前xx检测状态，
|
||
|
||
controller 收到某步骤返回结果后，先根据当前 后台 配置和该域名已完成步骤状态，解析该域名在本次流程中的下一勾选步骤；若存在下一步骤，则以标准化任务格式投入对应任务队列；若不存在，则标记本次流程完成
|
||
|
||
只按顺序处理后台勾选的任务
|
||
注册检测
|
||
百度检测
|
||
站长检测
|
||
爱站检测
|
||
时光机检测
|
||
聚查检测
|
||
桔子检测
|
||
|
||
备注：
|
||
时光机具体还要细分方案 ，目前项目内已经又对于的方案，加一个直晒前最近5年的快照，先跑通，后面可以继续细优化
|
||
步骤都是按后台勾选，把勾选的跑完就算流程跑完，第一次没勾选的，下次勾选，可以直接跑够选的步骤，其他跳过；
|
||
|
||
|
||
|
||
海外主库(域名源/最终账本)
|
||
↓
|
||
controller dispatcher 拉取待处理域名
|
||
↓
|
||
按 pipeline 配置生成首个待执行步骤任务
|
||
↓
|
||
推入 Redis 对应步骤队列
|
||
↓
|
||
worker 向 controller 拉取任务
|
||
↓
|
||
controller 认领并分配任务给 worker
|
||
↓
|
||
worker 执行检测并回传标准化结果
|
||
↓
|
||
controller stage-processor 更新本地控制状态
|
||
↓
|
||
根据结果判断：
|
||
- retry -> 重投当前步骤
|
||
- black_hit -> 拉黑并终止
|
||
- reject -> 终止/复核
|
||
- pass -> 解析下一勾选步骤并投递
|
||
↓
|
||
controller syncer 批量同步海外主库
|
||
↓
|
||
controller finalizer 标记本次流程完成
|
||
|
||
|
||
|
||
|
||
域名检测流程设计
|
||
1. 总体原则
|
||
海外主库负责域名源数据与最终账本持久化，不参与高频实时调度
|
||
controller 负责任务编排、任务分发、结果处理、状态推进与批量同步
|
||
Redis 负责各步骤待执行队列、运行中任务、重试任务与去重控制
|
||
worker 仅负责向 controller 拉取任务、执行对应检测函数、回传标准化结果
|
||
2. 注册任务投递
|
||
定时任务持续扫描海外主库中的待检测域名，包括未检测域名、快到期删除域名等
|
||
controller dispatcher 将符合条件的域名按标准化任务格式推入注册任务队列
|
||
3. 步骤执行规则
|
||
|
||
每个检测步骤执行完成后，无论结果如何，worker 均需返回标准化结果给 controller。
|
||
controller 根据结果类型做统一处理：
|
||
|
||
若为外部原因导致未得到有效结果，则根据重试策略重新投入当前步骤队列
|
||
若为业务判定不通过，则更新当前步骤状态，并按策略终止本次流程
|
||
若命中黑名单，则更新黑名单状态并终止后续所有步骤
|
||
若业务判定通过，则更新当前步骤状态，并根据本次 pipeline 配置解析下一勾选步骤，投入对应任务队列
|
||
4. pipeline 推进规则
|
||
所有步骤按后台勾选生成本次 pipeline
|
||
controller 仅按勾选顺序为单个域名推进下一步骤
|
||
若某步骤在本次 pipeline 中未勾选，则直接跳过
|
||
若前次未勾选、后次新增勾选，则可直接从已完成状态之后继续补跑，无需重跑已完成步骤
|
||
5. worker 拉取规则
|
||
worker 空闲时向 controller 发起拉取任务请求
|
||
controller 根据任务队列状态、任务顺序与后台配置返回当前可执行任务
|
||
worker 只负责执行任务，不负责流程判断、不负责决定下一步骤、不直接高频写海外主库
|
||
6. 状态更新规则
|
||
controller stage-processor 实时更新本地控制状态
|
||
controller syncer 以批量方式将步骤状态、黑名单状态、流程状态同步至海外主库
|
||
controller finalizer 在本次 pipeline 所有勾选步骤完成或流程被终止后，标记流程完成
|
||
7. 当前步骤顺序
|
||
|
||
按后台勾选顺序处理以下任务：
|
||
|
||
注册检测
|
||
百度检测
|
||
站长检测
|
||
爱站检测
|
||
时光机检测
|
||
聚查检测
|
||
桔子检测
|
||
8. 时光机一期方案
|
||
当前先按最近 5 年快照执行简化方案，先跑通主流程
|
||
后续再继续细化为更完整的时光机子流程
|
||
|
||
controller 机器如果性能足够剩余也可以部署worker 跑， |