KFS实时同步性能调优指南

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

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

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

KFS源端工作流：

KFS源端的工作流分为两个阶段：binlog-to-q, q-to-kufl.
binlog-to-q阶段，KFS从源端的数据库日志中抽取增量数据，经过extractor模块解析封装后，以DBMSEvent的形式在内存队列queue中暂存，此阶段的主要工作是将数据库的元组信息抽取转化为DBMSEvent，我们称此阶段为“解析”阶段。
q-to-kufl阶段，将队列中的DBMSEvent取出，封装为KUFLEvent，经过序列化成为KUFL持久化在外存文件中，此阶段主要是将内存中的数据转化为外存文件持久化，我们称此阶段为“存储”阶段。
KFS目标端工作流：

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.将增量数据加载到目标数据库

3性能诊断
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性能诊断流程
当我们进行性能诊断时，要优先分析瓶颈问题，然后从整体到局部逐渐分解，逐步向下找到问题所在，往往能够起到事倍功半的效果。

根据同步原理以及perf结果，我们可以得到一个如下所示的动作矩阵图：
源端

Stage（阶段）	Extraction	Applying
binlog-to-q	从事务日志获取增量	将增量放入内存队列
q-to-kufl	从内存队列中获取增量	1.将增量写入KUFL 2.更新数据库中的中间表断点

目标端

Stage（阶段）	Extraction	Applying
remote-to-kufl	通过网络从源端KUFL获取增量	将增量写入本地KUFL
kufl-to-q	从本地KUFL获取增量	将增量写入内存队列
q-to-dbms	从内存队列中获取增量	将增量加载到目标端数据库

由上图可以快速的知道每个阶段的每个动作所进行的操作。

3.2.1问题阶段定位
在确认性能问题所处的阶段时，我们是通过perf结果的Latency信息确认。
Latency最大的阶段即为当前瓶颈所处的阶段。

3.2.2问题动作定位
当确认完问题所处的阶段后，我们需要进一步明确：阶段中的哪个动作导致了瓶颈。根据3.1章节的perf结果可以得知，每个阶段的主要动作有以下几个：
Extraction、Filtering、Applying、Other。
而根据KFS的实现原理以及经验来看，Filtering和Other通常不会存在瓶颈，因此我们着重关注Extraction和Applying动作。
对于动作的瓶颈定位，由每个动作所消耗的时间确定，通常消耗时间最多的动作就是瓶颈所在。

3.3.3问题定位流程图
根据3.2.1和3.2.2章节中的方法，结合以下的流程图，我们可以知道当前运行中的大致问题是什么。

源端分析流程图：

目标端分析流程图：

4性能优化
由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，考虑从方案层面不同步此类数据。