提示：
Db2StreamingChangeEventSource类主要用于从 IBM Db2 数据库中读取变更数据捕获 (CDC, Change Data Capture) 信息。CDC 是一种技术，允许系统跟踪数据库表中数据的更改，这些更改可以是插入、更新或删除操作。在大数据和实时数据处理场景中，CDC 可以用来同步数据到其他系统，比如数据仓库、数据湖或者流处理平台如 Apache Kafka。
文章目录
前言
提示：Db2StreamingChangeEventSource 类的核心功能主要集中在实时地从 IBM Db2 数据库中捕捉和流式传输变更数据。
提示：以下是本篇文章正文内容
一、核心功能
核心功能详细说明
1. 实时变更数据捕获
- 目标:
Db2StreamingChangeEventSource的主要目标是从 Db2 数据库中实时捕捉任何数据表的变更，包括插入、更新和删除操作。 - 原理: 当在 Db2 数据库中启用 CDC 功能后，每次数据表中的数据发生变化时，Db2 都会在专门的 CDC 表中记录这些变更。
Db2StreamingChangeEventSource就是通过读取这些 CDC 表来获取变更数据的。 - 实时性: 这一过程是实时的，意味着一旦数据发生变化，
Db2StreamingChangeEventSource就能立即捕捉到这些变化，从而保证数据处理的时效性。
2. 流式数据处理与事件生成
- 流式处理: 捕捉到的变更数据不是简单地存储起来，而是被转化为事件流。这些事件可以被实时处理系统（如 Apache Kafka、Apache Flink 等）消费，进行进一步的处理或分析。
- 事件化: 每次数据变更都会生成一个事件，事件中包含了变更的具体信息，如变更类型（插入、更新、删除）、变更的时间戳、变更前后的数据等。
3. 错误恢复与容错机制
- 错误处理: 在读取和处理变更数据的过程中，可能会遇到各种错误，如 CDC 函数缺失、SQL 查询失败等。
Db2StreamingChangeEventSource内置了错误处理逻辑，能够识别并处理这些错误，防止整个数据流处理流程因个别错误而中断。 - 容错机制: 即便在出现错误的情况下，系统也能够从错误中恢复，继续处理后续的变更数据，确保数据流的连续性和系统的稳定性。
4. 偏移量上下文与状态追踪
- 偏移量上下文: 为了确保数据处理的准确性和一致性，
Db2StreamingChangeEventSource维护了一个偏移量上下文，记录了已经处理过的数据位置。这样，在系统重启或故障恢复后，可以从最后一次处理的位置继续，避免数据的重复处理或遗漏。 - 状态追踪: 通过偏移量上下文，系统能够追踪数据处理的状态，保证数据处理的完整性。
5. 性能优化与资源管理
- Metronome 控制: 为了避免频繁查询数据库导致的资源浪费，
Db2StreamingChangeEventSource使用 Metronome 控制查询的频率，确保既不会过度查询，又能及时捕捉变更。 - 资源管理: 通过合理安排查询频率和错误恢复策略，系统能够在保证数据处理效率的同时，有效管理资源，避免不必要的负载。
6. 模式变更适应
- 动态适应: 数据库表结构可能随时间变化，
Db2StreamingChangeEventSource具备检测和适应这些变化的能力，确保即使在表结构变更后，仍能正确读取和处理变更数据。
通过上述核心功能，Db2StreamingChangeEventSource 不仅能够实现实时的数据变更捕捉，还能确保数据处理的准确性、连续性和高效性，非常适合于需要实时数据同步、流数据分析和实时数据处理的应用场景。
二、代码分析
/** * 当数据库表结构更新时，数据库操作员应创建额外的捕获进程（及表）。此代码检测单个源表存在两个变更表的情况， * 根据存储在表中的LSN（日志序列号）来决定哪个是新表。循环从旧表流式传输变更直到新表中存在具有大于旧表LSN的事件。 * 随后切换变更表，并从新的表执行流式传输。 */ /** * 实现了DB2数据库使用CDC（变更数据捕获）的变更事件源。 * 本类负责从配置了CDC的DB2表获取变更，并将这些变更作为事件分发以供处理。 */ public class Db2StreamingChangeEventSource implements StreamingChangeEventSource<Db2Partition, Db2OffsetContext> { // 定义提交操作的LSN（日志序列号）列索引，用于追踪数据变更位置 private static final int COL_COMMIT_LSN = 2; // 定义行操作的LSN列索引，用于追踪数据变更位置 private static final int COL_ROW_LSN = 3; // 定义操作类型列索引，指示数据库操作类型（如插入、更新、删除） private static final int COL_OPERATION = 1; // 定义数据列索引，包含实际的数据变更 private static final int COL_DATA = 5; // 编译正则表达式，用于匹配CDC函数变化错误 private static final Pattern MISSING_CDC_FUNCTION_CHANGES_ERROR = Pattern.compile("Invalid object name 'cdc.fn_cdc_get_all_changes_(.*)'\\."); // 日志记录器 private static final Logger LOGGER = LoggerFactory.getLogger(Db2StreamingChangeEventSource.class); /** * 用于读取CDC表的连接。 */ private final Db2Connection dataConnection; /** * 用于检索时间戳的独立连接；没有它，自适应缓冲将无法工作。 */ private final Db2Connection metadataConnection; // 事件分发器 private final EventDispatcher<Db2Partition, TableId> dispatcher; // 错误处理器 private final ErrorHandler errorHandler; // 时钟服务 private final Clock clock; // 数据库模式 private final Db2DatabaseSchema schema; // 轮询间隔 private final Duration pollInterval; // 连接器配置 private final Db2ConnectorConfig connectorConfig; // 当前有效的偏移量上下文 private Db2OffsetContext effectiveOffsetContext; // 快照服务 private final SnapshotterService snapshotterService; /** * 构造Db2StreamingChangeEventSource对象。 * * @param connectorConfig 连接器配置信息 * @param dataConnection 用于读取CDC表的数据库连接 * @param metadataConnection 用于检索时间戳的数据库连接 * @param dispatcher 事件分发器 * @param errorHandler 错误处理器 * @param clock 时钟服务 * @param schema 数据库模式 * @param snapshotterService 快照服务 */ public Db2StreamingChangeEventSource(Db2ConnectorConfig connectorConfig, Db2Connection dataConnection, Db2Connection metadataConnection, EventDispatcher<Db2Partition, TableId> dispatcher, ErrorHandler errorHandler, Clock clock, Db2DatabaseSchema schema, SnapshotterService snapshotterService) { this.connectorConfig = connectorConfig; this.dataConnection = dataConnection; this.metadataConnection = metadataConnection; this.dispatcher = dispatcher; this.errorHandler = errorHandler; this.clock = clock; this.schema = schema; this.pollInterval = connectorConfig.getPollInterval(); this.snapshotterService = snapshotterService; }/** * 初始化Db2OffsetContext。 * * 此方法用于在任务启动或恢复时初始化offset上下文。它确保了即使传入的offsetContext为null， * 也能通过提供默认参数创建一个新的Db2OffsetContext，从而保证后续处理的正确性。 * * @param offsetContext 初始化用的offset上下文，如果为null，则使用默认参数创建一个新的上下文。 */ public void init(Db2OffsetContext offsetContext) { // 判断传入的offsetContext是否为null，如果不为null，则直接使用传入的实例； // 如果为null，则使用默认参数创建一个新的Db2OffsetContext实例。 this.effectiveOffsetContext = offsetContext != null ? offsetContext : new Db2OffsetContext(connectorConfig, TxLogPosition.NULL, false, false); } /** * 执行DB2数据库的变更数据捕获（CDC）流程。 * 此方法负责轮询数据库以获取变更、处理这些变更， * 并更新偏移量上下文以追踪处理位置。 * * @param context 变更事件源的上下文，用于检查执行是否应继续进行或暂停 * @param partition 数据库分区信息，用于确定要查询的表 * @param offsetContext 偏移量上下文，用于跟踪当前的处理位置和事务序列号 */ @Override public void execute(ChangeEventSourceContext context, Db2Partition partition, Db2OffsetContext offsetContext) throws InterruptedException { // 创建一个定时器，用于控制轮询间隔 final Metronome metronome = Metronome.sleeper(pollInterval, clock); // 创建一个优先队列，用于存储需要迁移的表变更信息 final Queue<Db2ChangeTable> schemaChangeCheckpoints = new PriorityQueue<>((x, y) -> x.getStopLsn().compareTo(y.getStopLsn())); try { // 创建一个原子引用，用于存储要查询的CDC表数组 final AtomicReference<Db2ChangeTable[]> tablesSlot = new AtomicReference<>(getCdcTablesToQuery(partition, offsetContext)); // 获取启动时记录在offset中的最后位置和序列号 final TxLogPosition lastProcessedPositionOnStart = offsetContext.getChangePosition(); final long lastProcessedEventSerialNoOnStart = offsetContext.getEventSerialNo(); LOGGER.info("启动时记录在offset中的最后位置是 {}[{}]", lastProcessedPositionOnStart, lastProcessedEventSerialNoOnStart); // 初始化最后处理的位置 TxLogPosition lastProcessedPosition = lastProcessedPositionOnStart; // 标记是否应立即增加LSN，仅在快照完成后首次运行时有效 boolean shouldIncreaseFromLsn = offsetContext.isSnapshotCompleted(); // 当执行上下文指示任务仍在运行时，持续执行循环 while (context.isRunning()) { // 获取数据库中的最大LSN final Lsn currentMaxLsn = dataConnection.getMaxLsn(); // 检查数据库中是否有最大LSN，如果没有则警告并暂停执行 if (!currentMaxLsn.isAvailable()) { LOGGER.warn("数据库中没有找到最大LSN；请确保DB2代理正在运行"); metronome.pause(); continue; } // 如果数据库中没有变化且需要增加LSN，则记录无变化并暂停执行 if (currentMaxLsn.equals(lastProcessedPosition.getCommitLsn()) && shouldIncreaseFromLsn) { LOGGER.debug("数据库中没有变化"); metronome.pause(); continue; } // 计算从哪个LSN开始读取，如果需要增加LSN则向前移动，但首次运行除外 final Lsn fromLsn = lastProcessedPosition.getCommitLsn().isAvailable() && shouldIncreaseFromLsn ? dataConnection.incrementLsn(lastProcessedPosition.getCommitLsn()) : lastProcessedPosition.getCommitLsn(); shouldIncreaseFromLsn = true; // 清空所有待迁移的表变更信息 while (!schemaChangeCheckpoints.isEmpty()) { migrateTable(partition, offsetContext, schemaChangeCheckpoints); } // 如果有新的变更表，则更新要查询的CDC表数组，并将新表添加到优先队列中 if (!dataConnection.listOfNewChangeTables(fromLsn, currentMaxLsn).isEmpty()) { final Db2ChangeTable[] tables = getCdcTablesToQuery(partition, offsetContext); tablesSlot.set(tables); for (Db2ChangeTable table : tables) { if (table.getStartLsn().isBetween(fromLsn, currentMaxLsn.increment())) { LOGGER.info("表结构将发生变更：{}", table); schemaChangeCheckpoints.add(table); } } } // 获取指定范围内的表变更，并处理这些变更 try { dataConnection.getChangesForTables(tablesSlot.get(), fromLsn, currentMaxLsn, resultSets -> { // 处理逻辑... }); // 更新最后处理的位置 lastProcessedPosition = TxLogPosition.valueOf(currentMaxLsn); // 终止事务，否则无法禁用表的CDC功能 dataConnection.rollback(); } catch (SQLException e) { // 处理SQL异常，重新设置要查询的表数组 tablesSlot.set(processErrorFromChangeTableQuery(e, tablesSlot.get())); } // 如果执行上下文指示应暂停，则暂停并等待快照完成 if (context.isPaused()) { LOGGER.info("流式处理现在将暂停"); context.streamingPaused(); context.waitSnapshotCompletion(); LOGGER.info("流式处理已恢复"); } } } catch (Exception e) { // 设置错误处理器的异常 errorHandler.setProducerThrowable(e); } }/** * 迁移表结构到新的分区。 * 此方法负责从队列中获取下一个待迁移的表结构信息，然后使用这些信息来更新表的结构。 * 这是处理数据库表结构变更的核心逻辑，它确保了数据迁移过程中表结构的一致性。 * * @param partition 当前的分区信息，用于标识数据所在的分区。 * @param offsetContext 用于存储和管理消费 offsets 的上下文信息。 * @param schemaChangeCheckpoints 表结构变更检查点的队列，包含待迁移的表结构信息。 * @throws InterruptedException 如果线程被中断。 * @throws SQLException 如果在操作数据库时发生错误。 */ private void migrateTable(Db2Partition partition, Db2OffsetContext offsetContext, final Queue<Db2ChangeTable> schemaChangeCheckpoints) throws InterruptedException, SQLException { // 从队列中获取下一个待处理的表结构变更信息 final Db2ChangeTable newTable = schemaChangeCheckpoints.poll(); // 日志记录当前正在迁移的表结构 LOGGER.info("Migrating schema to {}", newTable); // 从元数据连接中获取新表的结构 Table tableSchema = metadataConnection.getTableSchemaFromTable(newTable); // 更新offset信息，记录当前表结构变更的时间点 offsetContext.event(newTable.getSourceTableId(), Instant.now()); // 发送表结构变更事件，用于进一步处理和通知 dispatcher.dispatchSchemaChangeEvent(partition, offsetContext, newTable.getSourceTableId(), new Db2SchemaChangeEventEmitter(partition, offsetContext, newTable, tableSchema, schema, SchemaChangeEventType.ALTER)); // 更新表结构信息，用于后续操作 newTable.setSourceTable(tableSchema); }/** * 处理从变更表查询中获取的错误。 * 当遇到特定的CDC功能变化错误时，该方法将从当前变更表列表中移除不再被捕捉的表。 * * @param exception 查询变更表时发生的SQLException。 * @param currentChangeTables 当前的变更表数组。 * @return 如果匹配到特定错误，则返回经过过滤后的变更表数组；否则，重新抛出异常。 * @throws Exception 如果没有匹配的错误，或者在处理过程中发生其他错误，则抛出异常。 */ private Db2ChangeTable[] processErrorFromChangeTableQuery(SQLException exception, Db2ChangeTable[] currentChangeTables) throws Exception { // 使用预定义的正则表达式匹配SQL异常消息，以判断是否是特定的CDC功能变化错误。 final Matcher m = MISSING_CDC_FUNCTION_CHANGES_ERROR.matcher(exception.getMessage()); if (m.matches()) { // 如果匹配成功，提取错误消息中捕获实例的名称。 final String captureName = m.group(1); // 记录日志，说明哪个捕获实例不再被捕捉。 LOGGER.info("Table is no longer captured with capture instance {}", captureName); // 过滤掉与错误消息中捕获实例名称匹配的变更表，返回过滤后的变更表数组。 return Arrays.asList(currentChangeTables).stream() .filter(x -> !x.getCaptureInstance().equals(captureName)) .collect(Collectors.toList()).toArray(new Db2ChangeTable[0]); } // 如果没有匹配的错误，重新抛出原始异常。 throw exception; }/** * 获取需要查询的CDC表。 * * 此方法旨在从数据库中筛选出开启了CDC（Change Data Capture）功能的表，并进一步筛选出符合连接器配置的表。 * 如果表有多个捕获实例（capture instance），则会选择最新的实例。 * 对于新监测到的表，会触发架构变更事件以获取表的架构信息。 * * @param partition 分区信息，用于数据库查询。 * @param offsetContext 偏移上下文，用于存储和管理偏移信息。 * @return Db2ChangeTable数组，包含所有需要查询的CDC表。 * @throws SQLException 如果数据库查询发生错误。 * @throws InterruptedException 如果线程被中断。 */ private Db2ChangeTable[] getCdcTablesToQuery(Db2Partition partition, Db2OffsetContext offsetContext) throws SQLException, InterruptedException { // 获取所有开启了CDC的表 final Set<Db2ChangeTable> cdcEnabledTables = dataConnection.listOfChangeTables(); // 如果没有开启CDC的表，记录警告日志 if (cdcEnabledTables.isEmpty()) { LOGGER.warn("No table has enabled CDC or security constraints prevents getting the list of change tables"); } // 筛选符合连接器配置的表，并按表名分组 final Map<TableId, List<Db2ChangeTable>> includedAndCdcEnabledTables = cdcEnabledTables.stream() .filter(changeTable -> { // 如果表符合包括条件，则保留 if (connectorConfig.getTableFilters().dataCollectionFilter().isIncluded(changeTable.getSourceTableId())) { return true; } // 否则记录信息日志并排除 else { LOGGER.info("CDC is enabled for table {} but the table is not included by connector", changeTable); return false; } }) .collect(Collectors.groupingBy(x -> x.getSourceTableId())); // 如果没有符合要求的表，记录警告日志 if (includedAndCdcEnabledTables.isEmpty()) { LOGGER.warn(DatabaseSchema.NO_CAPTURED_DATA_COLLECTIONS_WARNING); } // 初始化存储最终结果的列表 final List<Db2ChangeTable> tables = new ArrayList<>(); // 遍历每个表的捕获实例 for (List<Db2ChangeTable> captures : includedAndCdcEnabledTables.values()) { Db2ChangeTable currentTable = captures.get(0); // 如果有多个捕获实例，选择LSN（Log Sequence Number）较大的作为当前实例，较小的作为未来实例 if (captures.size() > 1) { Db2ChangeTable futureTable; if (captures.get(0).getStartLsn().compareTo(captures.get(1).getStartLsn()) < 0) { futureTable = captures.get(1); } else { currentTable = captures.get(1); futureTable = captures.get(0); } // 设置当前实例的停止LSN为未来实例的开始LSN currentTable.setStopLsn(futureTable.getStartLsn()); // 将未来实例添加到结果列表 tables.add(futureTable); // 记录信息日志 LOGGER.info("Multiple capture instances present for the same table: {} and {}", currentTable, futureTable); } // 如果当前表的架构在schema中不存在，触发架构变更事件并添加到结果列表 if (schema.tableFor(currentTable.getSourceTableId()) == null) { LOGGER.info("Table {} is new to be monitored by capture instance {}", currentTable.getSourceTableId(), currentTable.getCaptureInstance()); // 更新偏移信息 offsetContext.event(currentTable.getSourceTableId(), Instant.now()); // 触发架构变更事件 dispatcher.dispatchSchemaChangeEvent( partition, offsetContext, currentTable.getSourceTableId(), new Db2SchemaChangeEventEmitter( partition, offsetContext, currentTable, dataConnection.getTableSchemaFromTable(currentTable), schema, SchemaChangeEventType.CREATE)); } // 将当前实例添加到结果列表 tables.add(currentTable); } // 将结果转换为数组并返回 return tables.toArray(new Db2ChangeTable[tables.size()]); }/** * 交易日志中变更位置的逻辑表示。 * 在每次数据源循环中，需要查询所有变更表，并对所有表中的变更进行全排序。<br> * 此类代表了在变更表上的开放数据库游标，能够向前移动游标并报告当前游标指向的变更的LSN（日志序列号）。 * * @author Jiri Pechanec * */ // 私有静态内部类：变更表指针 private static class ChangeTablePointer extends ChangeTableResultSet<Db2ChangeTable, TxLogPosition> { // 构造函数：初始化变更表指针 ChangeTablePointer(Db2ChangeTable changeTable, ResultSet resultSet) { super(changeTable, resultSet, COL_DATA); } /** * 从结果集中获取操作类型。 * * @param resultSet 结果集对象。 * @return 操作类型。 * @throws SQLException 如果发生SQL异常。 */ @Override protected int getOperation(ResultSet resultSet) throws SQLException { return resultSet.getInt(COL_OPERATION); } /** * 获取下一个变更的位置信息。 * * @param resultSet 结果集对象。 * @return 下一个变更的位置信息，如果已完成则返回NULL。 * @throws SQLException 如果发生SQL异常。 */ @Override protected TxLogPosition getNextChangePosition(ResultSet resultSet) throws SQLException { return isCompleted() ? TxLogPosition.NULL : TxLogPosition.valueOf(Lsn.valueOf(resultSet.getBytes(COL_COMMIT_LSN)), Lsn.valueOf(resultSet.getBytes(COL_ROW_LSN))); } }}
潜在问题
-
异常处理：
- 在
execute方法中，尽管捕获了InterruptedException和SQLException，但其他可能的异常（如自定义异常）没有被显式地处理。建议添加更细致的异常处理逻辑，以确保代码的健壮性。 - 当捕获到
SQLException时，通过processErrorFromChangeTableQuery方法处理，这个处理方式依赖于对错误消息的正则匹配，这可能在不同数据库版本或特定的错误情况下不那么可靠。
- 在
-
资源泄露：
- 在使用数据库连接和ResultSet等资源时，应确保在发生异常或完成操作后正确关闭这些资源，以避免潜在的资源泄露。建议使用try-with-resources语句来自动管理这些资源的关闭。
-
并发和同步：
- 代码中没有显示对于并发访问的控制，尤其是在多个线程可能同时访问和修改共享资源（如
dataConnection和metadataConnection）的情况下。如果这个类被设计为在多线程环境中使用，那么需要考虑添加适当的同步机制。
- 代码中没有显示对于并发访问的控制，尤其是在多个线程可能同时访问和修改共享资源（如
优化方向
-
代码可读性和维护性：
- 部分方法体较长，且逻辑较为复杂，这可能会影响代码的可读性和维护性。建议将一些逻辑分解为独立的方法，每个方法负责单一的逻辑，这样可以提高代码的可读性和可维护性。
-
性能优化：
- 在处理大量数据变更时，应考虑对数据库查询和数据处理进行优化，例如，通过调整查询语句的索引使用、批处理和缓存策略等来减少数据库的访问次数和提高处理效率。
- 考虑使用异步处理模式来提高执行效率，特别是在处理大量并发变更事件时。
-
日志记录：
- 虽然代码中使用了日志记录，但可以进一步优化日志的级别和内容，例如，在捕获异常时，记录更详细的上下文信息，这有助于问题的快速定位和解决。
-
配置化处理：
- 代码中一些硬编码的值（如列索引）可以考虑通过配置文件来管理，这样在列结构发生变化时，只需要修改配置文件而不需要修改代码，提高了代码的灵活性。
总结
提示：Db2StreamingChangeEventSource 类似乎是用于从 DB2 数据库中获取变更事件流的一个组件，特别适用于需要实时捕捉数据库表更改的应用场景。
问题：
当面对数千张表的变更数据捕获（CDC）场景时，传统的轮询方式确实可能导致较低的QPS（每秒查询率）。为了提高QPS性能，可以从以下几个角度进行优化：
-
并行处理：
- 实现多线程或多进程处理，让每个线程或进程专注于处理一部分表的变更数据。这样可以充分利用多核处理器的并行计算能力。
- 使用线程池管理线程，避免频繁创建和销毁线程的开销。
-
批量处理：
- 尝试将对数据库的请求批量化，一次处理多条变更记录，减少数据库I/O操作次数。
- 对于变更数据的读取，使用批量读取而不是逐条读取，可以显著减少网络延迟和数据库服务器的负载。
-
数据库优化：
- 确保数据库的索引和查询优化，特别是对CDC相关表的查询。
- 调整数据库的配置参数，如缓冲区大小、并发级别等，以适应高并发读取场景。
-
事件驱动模型：
- 考虑使用事件驱动的架构，比如利用数据库的发布/订阅机制或使用数据库的流式复制特性，这样可以实时响应变更事件，而不是定期轮询。
- 如果数据库支持，可以使用数据库的触发器或通知机制，当表中的数据发生变更时主动通知应用程序。
-
异步处理：
- 采用异步IO，如使用Java的
CompletableFuture或类似异步框架，可以避免阻塞等待数据库响应，提高整体的吞吐量。
- 采用异步IO，如使用Java的
-
缓存策略：
- 实现智能缓存策略，如LRU（最近最少使用）缓存，存储最近访问过的表的变更数据，减少对数据库的直接查询。
-
数据压缩：
- 对传输的数据进行压缩，减少网络带宽的消耗，加快数据传输速度。
-
微服务架构：
- 如果适用，可以将CDC处理逻辑拆分为微服务，每个微服务专门处理一组表，这样可以水平扩展处理能力。
-
监控与调优：
- 实施性能监控，持续监控系统瓶颈，根据监控数据进行针对性的优化。
- 定期进行性能测试和压力测试，评估优化效果。
-
使用专用工具或中间件：
- 考虑使用专门的CDC工具或中间件，如Debezium、Flink CDC等，它们通常已经过优化，可以高效处理大规模的变更数据捕获。
在具体实施时，可能需要结合具体情况选择适合的优化策略。例如，如果是在云环境中，可以利用云平台提供的弹性伸缩能力，自动调整资源以应对负载变化。
对于代码本身，如果要进行并行处理，可以考虑使用Java的ExecutorService来管理线程池，使用Future或CompletableFuture来处理异步结果。批量处理可以通过修改数据库查询语句，一次性获取多条变更记录。同时，确保所有并发操作都正确处理了同步和线程安全问题。