一、概述

1.1什么是性能

性能是一种指标，表明软件系统对于其及时性要求的符合程度。及时性用响应时间或者吞吐量来衡量。
响应时间是对请求做出响应所需要的时间。对于单个事务可以是事务完成所需要的时间；对于用户任务，则是端对端的时间。例如，一个在线系统要求在用户按下回车键后的 0.5 秒内产生结果。
系统吞吐量是指特定时间内能够处理的请求数量。例如，对电话交换机的要求则是每秒钟能够处理 1000000 次呼叫。
软件性能的及时性包括两个重要方面：响应性和可扩展性。
响应性是系统实现其响应时间或者吞吐量目标的能力。
可扩展性则是系统在对其软件功能的要求增加的情况下，继续实现其响应时间或吞吐量目标的能力

1.2实时同步工具性能指标

实时同步响应时间：即一条数据在源端数据库写入，到目标端数据库中可以查询到该数据的时间间隔，其大小=源端解析时间+传输时间+目标端入库时间。
实时同步吞吐量：即单位时间内，同步工具可以同步的增量数据量大小。

二、同步原理概述

在分析实时同步中的性能问题之前，我们先来了解KFS同步的一些基本原理以及流程，以便后续分析性能瓶颈。

KFS源端工作流：

KFS源端的工作流分为两个阶段：解析，存储
解析阶段，KFS从源端的数据库日志中抽取增量数据，经过解析模块解析为数据库事物信息后存放在内存中。
存储阶段，将内存中的事务信息封装为统一的中间件存储在磁盘中。

KFS目标端工作流：

KFS目标端工作流分为三个阶段：传输，反向解析，入库.
传输阶段： 通过网络将源端封装的kufl中间数据传输至目标端
反向解析：阶段，KFS将本地的KUFL中反序列化成为KUFLEvent，同时解析为DBMSEvent存储在内存队列queue中。
入库阶段，将内存队列中的增量数据加载到目标数据库

三、性能瓶颈判断

3.1性能诊断工具

KFS在安装完成后，可以使用fsrepctl perf命令进行同步过程中的性能诊断。
使用方式为：
在服务ONLINE状态下，执行fsrepctl –service xxx perf，其中xxx为服务名。
对于源端和目标端服务，该命令的输出结果会存在差异。

源端

目标端

Perf结果解析：
Stage：表示当前服务的工作阶段。
源端的工作阶段有：binlog-to-q（源端解析））和q-to-kufl（源端存储），目标端的工作阶段有：
remote-to-kufl（传输）、kufl-to-q（目标端解析）、q-to-dbms（入库）。详细参考第2节“同步原理概述”。

Seqno：表示对应阶段正在处理的事务seqno号，一个seqno对应数据库中的一个事务。
Latency：表示对应阶段当前的延迟时间，单位秒。
Events：表示对应阶段运行至今所处理的事务frag数量，一个seqno中可能包含1个或多个frag。
Extraction：表示对应阶段的抽取动作消耗的时间。
Filtering：表示对应阶段的过滤动作消耗的时间。
Applying：表示对应阶段的应用动作消耗的时间。
Other：其他时间消耗，可忽略。
Total：该阶段的所消耗的总时间。

由于Filtering过程较为简单，即利用cpu对内存中的事务进行计算，通常不存在瓶颈，因此本文省略对该阶段的分析。

3.2性能诊断流程

根据同步原理以及fsrepctl perf性能诊断工具所诊断的结果，综合分析，即可知道性能每个阶段的矩阵图，从整体到局部逐级分解，可以快速定位问题瓶颈点
根据同步原理以及perf结果，我们可以得到一个如下所示的动作矩阵图：
源端

目标端

由上图可以快速的知道每个阶段的每个动作所进行的操作，根据perf结果中的Latency信息确认，Latency最大的阶段即为当前瓶颈所处的阶段

3.3 问题动作定位

根据KFS工作原理和经验来看，filter和other动作基本不会存在瓶颈，主要关注extraction和applying，通过下图所示的分析流程图，可以知道运行过程中大致的问题是什么。

源端分析流程图：

目标端分析流程图：

四、性能优化

由3.3.3章节可以得出对应的性能问题，本章节将对各个问题的有哪些优化手段进行详细说明。

4.1网络问题优化

对于KFS来说，网络问题的优化方式通常有2种：
1.改善网络质量，增大带宽
2.将存在网络问题的组件集中部署，例如，源端数据库和源端KFS集中部署，目标端数据库和目标端KFS集中部署。

4.2KFS所在机器CPU问题

此问题一般是当前的硬件环境下，KFS的解析效率已经达到极限，那么解决这个方法，可以从两个方面入手：
1.增强相关的硬件性能，如增加cpu主频。
2.减少解析的量，通过配置底层过滤在日志中将无需解析的表过滤。
property=replicator.extractor.dbms.lowLevelFilter=true
property=replicator.extractor.dbms.tablePatterns=public.,mytest.

4.3JVM内存不足

配置方法
通过调整flysync.ini中的repl_java_mem_size参数完成。
参数单位为m，配置时无需加单位。

所需内存大小计算方式
源端：该服务设置的大事务分片数平均每条数据大小（该源端关联的目标端数量+1）
目标端：该服务对应的源端设置的大事务分片数*平均每条数据大小

4.4频繁更新中间表断点问题

在源端flysync.ini中配置：
property=replicator.pipeline.master.syncKUFLWithExtractor=false

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

4.5磁盘写入效率低

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

4.6网络带宽问题

同4.1优化思路。

4.7数据库加载慢

该问题通常和业务相关，因此优化手段也需要根据业务不同而变化。

首先，有以下通用配置可以先检查是否可以调整。

1. 批量入库
   property=replicator.applier.dbms.optimizeRowEvents=true
   property=replicator.applier.dbms.maxRowBatchSize=20
   大小通常设置为500~2000即可，可根据实际内存调整。
2. Jdbc插入优化（仅限KESV8数据源）
   property=replicator.datasource.global.connectionSpec.urlOptions=socketTimeout=60&preferQueryMode=extendedForPrepared&
   reWriteBatchedInserts=true
3. 内存队列缓冲池大小
   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，考虑从方案层面不同步此类数据。