1. 概述
1.1 版本
| FineDataLink版本 | 功能变动 |
|---|---|
| 4.2.4.3 | - |
| 4.2.14.1 | 实时采集任务运行逻辑优化 |
| 4.2.17.4 | 采集任务重试逻辑优化 |
1.2 应用场景
当多个实时任务、实时管道任务对同一个数据库的不同表进行实时同步时，会重复解析数据库的日志，导致数据库压力过大，特别是在实时任务场景下，不同表会在不同实时任务中处理，就很容易导致日志被解析多次。
1.3 功能简介
实时采集任务支持对数据库日志解析进行管理，存储日志解析产生的变更数据，实时任务/实时管道任务能够消费实时采集任务的数据。
注：所有实时任务/实时管道任务的 CDC 输入，都默认走实时数据采集任务。
2. 实时管道/实时任务与采集任务关系
2.1 架构演进
2.1.1 历史架构
在早期架构中，实时管道任务是一个完全独立的、端到端的单元。每个管道任务都内置了完整的 E-T-L（抽取-转换-加载）能力。这意味着，每创建一个实时管道任务，系统就会启动一个独立的进程，该进程会直接连接到源端数据库，执行日志读取（如 Oracle Logminer、MySQL Binlog）或 CDC 表查询操作。
这种模式的弊端在高并发、多任务场景下尤为突出：
源端压力巨大：如果有 10 个管道任务需要从同一个 Oracle 数据库同步数据，就会建立 10 个独立的 Logminer 连接。这会急剧增加源端数据库的 CPU 和 I/O 负担，甚至影响核心业务的稳定性。
资源浪费严重：每个管道任务都在重复地执行相同的“日志读取”和“数据解析”工作，造成了计算和网络资源的极大浪费。
扩展性受限：每增加一个管道任务，对源端的压力就增加一分，使得整个数据同步系统的横向扩展能力受到源端数据库性能的严重制约。
2.1.2 全新架构：采集任务与管道任务的分离
新架构引入了「实时数据共享中心」的概念，其核心思想就是“采传分离”（采集与传输分离）。
我们将数据读取（采集）的能力从实时管道任务中剥离出来，形成一个独立的、可共享的单元——采集任务。
| 类型 | 说明 |
|---|---|
| 采集任务 | 职责： 连接到一个特定的数据源（例如一个数据库实例），并持续不断地捕获其数据变更事件（增、删、改），并将这些数据标准化后推送到一个内部的高速消息队列（如 Kafka）中 特性： 一个采集任务对应一个数据源。它是一个可被多个下游任务复用的共享资源 |
| 实时管道任务/实时任务 | 职责： 专注于数据的“消费、转换与加载”。它不再直连源端数据库进行日志解析，而是从一个或多个已经配置好的“采集任务”那里订阅并获取数据 特性： 一个或多个实时管道任务可以订阅消息队列（从 Kafka 中）。每个实时管道任务根据自身的配置，只从队列中拉取自己感兴趣的表的数据进行后续处理 |
1.3 功能简介
2. 实时采集任务运行说明
2.1 新建实时采集任务
2.1.1 新建流程
1）点击「管理系统>数据连接>实时采集任务」，设置 缓存设置
2）创建实时管道或者实时任务后，在「管理系统>数据连接>实时采集任务」中自动新增实时采集任务，不需要用户手动新增。如下图所示：
2.1.2 实时采集任务与数据连接关系
4.2.14.1 之前版本：
采集任务根据数据连接URL来区分：
如果不同数据连接URL完全一致，只会创建一个实时采集任务。
数据连接URL发生变化，比如加个空格/加个后缀参数之类，就会创建一个新的采集任务。
4.2.14.1 及之后版本：
采集任务以「数据连接的名称」来区分。
2.1.3 示例说明
注：重置启动实时管道任务/实时任务，相当于新建任务，参考下方表格说明即可。
| 场景 | 说明 |
|---|---|
已有实时采集任务，新建一个新表的任务：
| 任务启动时，在实时采集任务1中自动新增table3的日志解析：
|
已有实时采集任务，新建一个已存在表的任务：
| 任务1直接使用实时采集任务1收集的日志数据： 1）当任务1使用「全量+增量」或「启动时间」时，使用实时采集任务1 2）当任务1使用「自定义时间」时：
|
2.2 暂停/中止实时管道或实时任务对采集任务的影响
4.2.14.1 之前版本：
| 场景 | 说明 |
|---|---|
| 检查任务中使用的所有来源表的CDC数据是否有其他任务在使用：
|
| 检查任务中使用的所有来源表的CDC数据是否有其他任务在使用：
|
4.2.14.1 及之后版本：
当实时管道/实时任务暂停时，不再自动触发采集任务中表的暂停（若实时采集任务中存在表未被使用，会进行提示；同时，实时采集任务中支持 手动删除表 ）。
2.3 删除实时管道或实时任务对采集任务的影响
4.2.14.1 之前版本：
| 场景 | 说明 |
|---|---|
| 删除任务时，检查任务中使用的所有来源表的CDC数据是否有其他任务在使用：
|
| 删除任务时，检查任务中使用的所有来源表的CDC数据是否有其他任务在使用：
|
4.2.14.1 及之后版本：
当实时管道/实时任务删除时，不再自动触发采集任务中表的删除（若实时采集任务中存在表未被使用，会进行提示；同时，实时采集任务中支持 手动删除表 ）。
2.4 启动实时管道任务或实时任务对采集任务的影响
| 场景 | 说明 |
|---|---|
| 恢复任务时，检查任务中使用的所有来源表的CDC数据是否在收集： 1）如果是在收集，说明有其他任务正在使用这些表的CDC数据，按照当前任务的断点从实时数据共享中心取数进行同步即可
2）如果没有在收集，说明也没有其他任务正在使用这些表的CDC数据，自动恢复启动该实时采集任务收集，继续收集table1、table2、table3的数据，按照当前任务的断点从实时数据共享中心取数进行同步即可
3）任务1恢复启动时，有三种情况：
|
| 恢复任务时，检查任务中使用的所有来源表的CDC数据是否在收集： 1）如果是在收集，说明有其他任务正在使用这些表的CDC数据，按照当前任务的断点从实时数据共享中心取数进行同步即可
2）如果没有在收集，说明也没有其他任务正在使用这些表的CDC数据，自动恢复启动该实时采集任务收集，继续收集table1的数据，按照当前任务的断点从实时数据共享中心取数进行同步即可
|
4.2.14.1 及之后版本，逻辑优化：
1）当采集任务被手动暂停后，因为某一个实时任务重新触发启动时，启动时就恢复所有表的采集。
2）当实时管道、实时任务恢复启动时：
对应的采集任务不存在或者对应的表不存在时，实时管道报表级错误、实时任务报任务级错误；采集任务中，报错：没有解析${表名}的数据，请重新同步，自动添加该表的解析
对应的表运行错误时，实时管道报表级错误、实时任务报任务级错误；采集任务中，报错：${表名}解析错误，请重新同步，自动重置该表的解析
对应的表最早消息时间晚于所需时间时，实时管道报表级错误，实时任务报任务级错误；采集任务中，${表名}的增量数据已过期，请重新同步
2.5 实时采集任务运行错误
| 场景 | 说明 |
|---|---|
实时采集任务从运行中→ 运行错误：
|
所有依赖实时采集任务1的任务全部运行错误中止，并且打印出实时采集任务1具体的错误原因 用户按照具体的错误原因，采取针对性的操作即可 |
实时采集任务被异常停止：
|
|
2.6 实时采集任务中表异常
1）实时采集任务中表的异常情况都在实时、管道任务中体现。
当实时采集任务中表运行错误、异常删除时，依赖该实时采集任务的实时任务报错中止，实时管道任务移除异常表的同步，正常的表照常同步，当实时管道任务中所有表都异常时，管道任务才整体报错。
比如解析相应时间点的日志时，如果相应时间点的日志丢失，则实时采集任务报错中止、依赖该实时采集任务的任务也报错。
2）当新建的实时任务、实时管道任务的启动时间早于实时数据共享中心的数据最早的数据时，会自动补齐数据。
2.7 对实时任务、实时管道的影响
1）实时采集任务将数据库中所有CDC数据都写入到实时数据共享中心，由各个业务决定使用哪一类数据。比如对于 DDL 的数据，数据管道会进行使用，实时任务暂时没有使用 DDL 的功能。
提示:实时采集任务暂不支持脏数据容忍，遇到脏数据时，先走重试逻辑，重试 3 次失败后，则实时采集任务报错中止
1）4.2.17.4 之前版本，如果报错相同，不会重置重试次数，即重试三次后，再遇到相同报错，不会进行重试；若遇到不同报错，会进行第一次重试。
2）4.2.17.4 及之后版本，只要异常距离上次启动时间超过 30 分钟，重置重试次数。
2）对实时、管道任务运行逻辑的变动：
1）重试逻辑：管道、实时任务的重试不控制与 CDC 数据源的重试，只控制管道和实时数据共享中心连接的重试和其输出端的重试。
2）删除表情况：
实时任务需要基于删除的 ddl 事件，报错中止、打印相应报错日志，并触发相应的结果通知。
实时管道任务会基于删除表的ddl事件，触发通知和打印日志，继续同步其他表。
3）自定义同步时间：在实时任务、实时管道任务中同步方式选择「自定义时间」时，可以设置「数据库日志最早时间」和「共享中心最早时间」中的最早时间；实时管道任务中需要取「当前任务的所有表各自的最早时间」中的最晚时间。
4）恢复启动：当实时、管道任务恢复启动时，如果实时数据共享中心中最早的数据晚于断点时间，任务报错中止。
上一篇：缓存配置
