开个定时任务不停扫数据库，未检测的 快到期删除的，全部扫出来推送给注册任务队列； 注册检测：筛选出可以注册的，这个完成后，不管成功失败，返会标准化结果给 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.去后台点击 聚名获取删除域名入库 2.按后台勾选 的检测选项，按顺序逐个去跑 3.正常逻辑是按顺序 一步一步前面的处理完了，再往下一个处理，最大进程跑起来，直到所有任务跑完 现在遇到的问题是： 1.后台展示文案的歧义非常大；运营很难理解 比喻托管节点：这个应该就是 服务器管理，现在你把进程也算是一个节点，全部放到这个列表，我看起来都蒙，如果需要你可以加多一个进程管理不就好了，不要混一起 现在后台应该有 机器/进程/线程，节点到底是啥？现在已经乱了， 运行配置这块也是 节点独立线程覆盖 你把所有进程都列出来配置 线程数量，这个不需要的，所有进程的线程数量全部走默认的，进程那么大不会人工管理的，设计很不合理， 检测管理页面：日志输出窗口 这块也是 参与节点：3 这个应该改成 参与 服务器 参与进程：62 参与 进程 参与 线程 运行中：127 线程：127 / 74000（参与节点汇总） 要让人一眼看明白 2.最重要一点，后台页面的数据展示很多都是不符合实际的，很多一点，为啥黑名单一直是0，这块不肯定的，这个正常清空最少命中80%； 进程和线程一直跑不起来，这个最致命，优化了好几日了，知道目前还是没跑通完整流程 3.概览 步骤队列 看每一步堆积、吞吐和失败，快速判断到底卡在注册、百度、360、爱站还是站长之家。 这块应该按后台勾选设置的顺序拍下来，正常任务完成也是，一个跑完才会往下推，才会往下一个跑 4.检测的进程和线程 机器 不稳定，不会自动检测 自动跑起来，就是最大性能没有跑起来 5.如果大陆controller 的DB链接数量是瓶颈，那可以每个大陆 机器都开启db+redis 反正每个机器的配置都很高的，只要有效率能提速 6.还有一个但海外机器绝对不参与worker 检测 一句话结论： 线上 hotfix 收口基本完成 下一步最该继续的是代理供给优化，不是回到代码审核 我下一步建议就直接转到代理链路，继续收： 为什么多实例同时刷新时会被代理源限流 是否要继续压低单实例补货批量/频率 是否要做更强的跨进程代理补货协调 大陆处理好的跑完流程域名是否返回海外机器勾选状态 域名检测流程设计 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 跑，