人大金仓KFS实时同步目标端性能优化指南

关键字：

数据同步，目标端入库，性能、人大金仓

概述

程序的性能是指计算机程序在执行任务时所表现出的速度、效率和稳定性等方面的度量。性能的好坏直接影响到程序的用户体验和开发成本。优化程序性能通常包括提高代码质量、减少资源消耗、采用更高效的算法和技术等方面。本文将简要介绍KFS实时同步目标端的性能定位方案。

实时同步流程概述

KFS源端的工作流分为两个阶段：binlog-to-q, q-to-kufl.

binlog-to-q阶段，KFS从源端的数据库日志中抽取增量数据，经过extractor模块解析封装后，以DBMSEvent的形式在内存队列queue中暂存，此阶段的主要工作是将数据库的元组信息抽取转化为DBMSEvent，我们称此阶段为“解析”阶段。

q-to-kufl阶段，将队列中的DBMSEvent取出，封装为KUFLEvent，经过序列化成为KUFL持久化在外存文件中，此阶段主要是将内存中的数据转化为外存文件持久化，我们称此阶段为“存储”阶段。

KFS目标端工作流分为三个阶段：remote-to-kufl, kufl-to-q, q-to-dbms.

remote-to-kufl阶段，KFS目标端通过主动访问源端的监听，建立TCP连接，从源端的KUFL文件中反序列化按顺序将KUFLEvent获取，获取完成后序列化成为KUFL存储在本地,此阶段的主要任务是将源端的文件发送到目标端，我们将此阶段称为“传输”阶段。

kufl-to-q阶段，KFS将本地的KUFL中反序列化成为KUFLEvent，同时解析为DBMSEvent存储在内存队列queue中。

q-to-dbms阶段，applier将内存中的DBMSEvent取出，同时将其翻译成为SQL语句，应用到目标端数据库中，此阶段的主要目的是将数据入库，因此我们将此阶段称为“入库”阶段。

简要来说，各个阶段所进行的活动如下：

源端

binlog-to-q：1.从事务日志获取增量数据 2.将增量数据放入内存队列

q-to-kufl：1.从内存队列中获取增量数据 2.将增量数据写入KUFL文件持久化 3.更新数据库中间表中的断点位置。

目标端

remote-to-kufl：1.通过网络从源端获取增量数据 2.将增量数据写入KUFL文件持久化

kufl-to-q：1.从本地KUFL文件获取增量数据 2.将增量数据放入内存队列

q-to-dbms：1.从内存队列中获取增量数据2.将增量数据加载到目标数据库

目标端入库优化指南

网络问题优化

对于KFS来说，网络问题的优化方式通常有2种：

1. 改善网络质量，增大带宽
2. 将存在网络问题的组件集中部署，例如，源端数据库和源端KFS集中部署，目标端数据库和目标端KFS集中部署。

KFS所在机器CPU问题

此问题一般是当前的硬件环境下，KFS的解析效率已经达到极限，那么解决这个方法，可以从两个方面入手：

1. 增强相关的硬件性能，如增加cpu主频。
2. 减少解析的量，通过配置底层过滤在日志中将无需解析的表过滤。

property=replicator.extractor.dbms.lowLevelFilter=true

property=replicator.extractor.dbms.tablePatterns=public.,mytest.

JVM内存不足

配置方法

通过调整flysync.ini中的repl_java_mem_size参数完成。

参数单位为m，配置时无需加单位。

所需内存大小计算方式

源端：该服务设置的大事务分片数平均每条数据大小（该源端关联的目标端数量+1）

目标端：该服务对应的源端设置的大事务分片数*平均每条数据大小

频繁更新中间表断点问题

在源端flysync.ini中配置：

property=replicator.pipeline.master.syncKUFLWithExtractor=false

该参数配置后，KFS将不在向源端数据库中更新断点，断点信息全部存储在KUFL当中，需要注意的是，若KUFL也被清除，那么KFS再次启动时将无法获取断点，从当前最新位置启动。

磁盘写入效率低

此问题暂时没有较好的解决手段，只能通过增强相关硬件的方式处理。

如使用SSD盘。

网络带宽问题

同网络问题优化思路。

数据库加载慢

批量入库

property=replicator.applier.dbms.optimizeRowEvents=true

property=replicator.applier.dbms.maxRowBatchSize=20

大小通常设置为500~2000即可，可根据实际内存调整。

Jdbc插入优化（仅限KESV8数据源）

property=replicator.datasource.global.connectionSpec.urlOptions=socketTimeout=60&preferQueryMode=extendedForPrepared&

reWriteBatchedInserts=true

内存队列缓冲池大小

property= replicator.global.buffer.size=100

大小通常设置为10~200，可根据实际内存调整。

除了上述通用参数之外，还有以下和业务强相关的场景。

1. 小事务较多，无法进行批量

2. 数据集中在某些表上，分布不均匀，导致入库效率低

3. update、delete较多，并且执行慢

4. 存在跑批类型的数据

对于问题1,2，我们考虑采用多通道并行入库的方式进行。

配置方法如下：

1）在flysync.ini文件中增加以下内容：

svc_parallelization_type=memory

channels=4

property=replicator.store.parallel-queue.partitionerClass=com.kingbase.flysync.replicator.storage.parallel.ShardListPartitioner

同时，在目标端原有的过滤器后面追加新的过滤器：

shardbytable

2）找到static文件同级目录下的shard.list文件。在最下面添加：

public_a1=0

public_a2=1

public_a3=2

public_a4=3

(*)=0

public_a1=0 含义为:public.a1表走通道0

public_a2=1 含义为:public.a2表走通道1

public_a3=2 含义为:public.a3表走通道2

public_a4=3 含义为:public.a4表走通道3

(*)=0 含义为：其他未配置的表默认走通过0

对于问题3，确定是否存在索引，若没有则需要增加索引。

对于问题4，考虑从方案层面不同步此类数据。