mycat 优化

时间 2019-12-05

标签 mycat 优化繁體版

原文原文链接

版权声明：本文为博主原创文章，未经博主容许不得转载。 https://blog.csdn.net/u014180504/article/details/76595247
show @@datanode;
该命令用于显示MyCAT的数据节点的列表，对应schema.xml配置文件的dataNode节点

其中，“NAME”表示dataNode的名称；“dataHost”表示对应dataHost属性的值，即数据主机；“ACTIVE”表示活跃链接数；“IDLE”表示闲置链接数；“SIZE”对应总链接数量。

显示后端物理库链接信息，包括当前链接数，端口
Show @@backend

Show @@connection
显示当前前端客户端链接状况，已经网络流量信息

Show @@threadpool
当前线程池的执行状况，是否有积压(active_count)以及task_queue_size，后者为积压的待处理的SQL，若积压数目一直保值，则说明后端物理链接可能不够或者SQL执行比较缓慢。

Show @@heartbeat
当先后端物理库的心跳检测状况,RS_CODE为1表示心跳正常

Show @@datanode
显示数据节点的访问状况，包括每一个数据节点当前活动链接数(active),空闲链接数（idle）以及最大链接数(maxCon) size，EXECUTE参数表示从该节点获取链接的次数，次数越多，说明访问该节点越多。

Show @@processor
显示当前processors的处理状况，包括每一个processor的IO吞吐量(NET_IN/NET_OUT)、IO队列的积压状况(R_QUEY/W_QUEUE)，Socket Buffer Pool的使用状况BU_PERCENT为已使用的百分比、BU_WARNS为Socket Buffer Pool不够时，临时创新的新的BUFFER的次数，若百分比常常超过90%而且BU_WARNS>0，则代表BUFFER不够，须要增大，参见性能调优手册。

Show @@datasource
显示数据源的信息，是不是读写节点等。

show @@cache
显示缓存的使用状况，对于性能监控和调优颇有价值
MAX为缓存的最大值（记录个数），CUR为当前已经在缓存中的数量，ACESS为缓存读次数，HIT为缓存命中次数，PUT 为写缓存次数，LAST_XX为最后操做时间戳，比较重要的几个参数：CUR：若CUR接近MAX，而PUT大于MAX不少，则代表MAX须要增大，HIT/ACCESS为缓存命中率，这个值越高越好。

Kill @@connection
杀掉客户端的链接，参数为链接的ID值，经过show @@connection，能够展现当前链接到MyCAT的全部客户端进程，若某个进程异常，则能够经过该命令杀掉链接，如
KILL @@CONNECTION 1;

JVM调优：

内存占用分两部分:Java堆内存+直接内存映射（DirectBuffer占用），建议堆内存

适度大小，直接映射内存尽量大，两种一块儿占据操做系统的1/2-2/3的内存。

下面以服务器16G内存为例，Mycat堆内存4G，直接内存映射6G，JVM参数如

下：

-server -Xms4G –Xmx4G   XX:MaxPermSize=64M -XX:MaxDirectMemorySize=6G

用mycat console等命令启动MyCAT的，JVM参数都在conf\wrapper.con文件中，下面是一段实例：

# Java Additional Parameters

wrapper.java.additional.5=-XX:MaxDirectMemorySize=2G wrapper.java.additional.6=-Dcom.sun.management.jmxremote # Initial Java Heap Size (in MB) wrapper.java.initmemory=2048 # Maximum Java Heap Size (in MB) wrapper.java.maxmemory=2048 操做系统调优：

最大文件句柄数量的修改，设置为5000-1万，在Mycat Server和MySQL数据库的机器上都设置。Linux操做系统对一个进程打开的文件句柄数量的限制(也包含打开的SOCKET数量,可影响mysql的并发链接数目).这个值可用ulimit命令来修改，但ulimit命令修改的数值只对当前登陆用户的目前使用环境有效,系统重启或者用户退出后就会失效。

Mysql调优：

最大链接数设置为2000

[mysqld]中有参数

max_connections = 2000

mysql> show global status like 'Max_used_connections';

MySQL服务器过去的最大链接数是245，没有达到服务器链接数上限256，应该没有出现1040错误，比较理想的设置是：

Max_used_connections / max_connections * 100% ≈ 85%

最大链接数占上限链接数的85%左右，若是发现比例在10%如下，MySQL服务器链接上线就设置得太高了。

Mycat调优：

Conf/log4j.xml中，日志级别调整为至少info级别，默认是debug级别，用于排查错误，不能用于性能测试和正式生产中。

conf/server.xml中有以下参数能够调整： <system>

<!— CPU核心数越多，能够越大，当发现系统CPU压力很小的状况下，能够适当调大此参数，如4核心的4CPU，能够设置为16，24核心的能够最大设置为128——>

<property name="processors">1</property>

下面这个参数为每一个processor的线程池大小，建议能够是16-64，根据系统能力来测试和肯定。

<property name="processorExecutor">16</property>

</system>

System中如下重要参数也根据状况进行调整

processorBufferPool ：每一个processor分配的Socket Direct Buffer，用于网络通讯，每

个processor上管理的全部链接共享，processorBufferChunk为Pool的最小分配单元，每一个POOL的容量即为processorBufferPool/processorBufferChunk，默认前者为1024 * 1024 * 16=16M，后者为4096字节。processorBufferPool参数的调整，须要观察show @@processor的结果来肯定：

BU_PERCENT为已使用的百分比、BU_WARNS为Socket Buffer Pool不够时，临时创新的新的BUFFER的次数，若百分比常常超过90%而且BU_WARNS>0，则代表

BUFFER不够，须要增大processorBufferPool。基本上，链接数越多，并发越高，须要的POOL越大，建议BU_PERCENT最大在40-80%之间。

conf/schema.xml中有以下参数能够调整：

<schema name="TESTDB" checkSQLschema="true"> ，checkSQLschema属性建议设置为false，要求开发中，不能在sql中添加数据库的名称，如select * from TESTDB.company，这样能够优化SQL解析。

<dataHost name="localhost1" maxCon="500" minCon="10" balance="0"

dbType="mysql" dbDriver="native" banlance="0">

<!—最大链接池maxCon，能够改成1000至2000，同一个Mysql实例上的全部datanode节点的共享本dataHost 上的全部物理链接à

性能测试的时候，建议minCon=maxCon= mysql max_connections

设为2000左右。

另外，读写分离是否开启，根据环境的配置来决定。

缓存优化调整：

Show @@cache命令展现了缓存的使用状况，常常观察其结果，须要时候进行调整：

通常来讲：若CUR接近MAX，而PUT大于MAX不少，则代表MAX须要增大， HIT/ACCESS为缓存命中率，这个值越高越好。从新调整缓存的最大值之后，观测指标都会跟随变化，调整是否有效，主要观察缓存命中率是否在提高，PUT则降低。

目前缓存服务的配置文件为：cacheservice.properties，主要使用的缓存为enhache，enhache.xml里面设定了enhance缓存的全局属性，下面定义了几个缓存：

#used for mycat cache service conf

factory.encache=org.opencloudb.cache.impl.EnchachePooFactory

#key is pool name ,value is type,max size, expire seconds

pool.SQLRouteCache=encache,10000,1800

pool.ER_SQL2PARENTID=encache,1000,1800

layedpool.TableID2DataNodeCache=encache,10000,18000

layedpool.TableID2DataNodeCache.TESTDB_ORDERS=50000,18000

l SQLRouteCache为SQL 解析和路由选择的缓存，这个大小基本相对固定，就是全部 SELECT语句的数量。

l ER_SQL2PARENTID为ER分片时候，根据关联SQL查询父表的节点时候用到，没有用到 ER分片的，这个缓存用不到

l TableID2DataNodeCache，当某个表的分片字段不是主键时，缓存主键到分片ID的关系，这个是二层的缓存，每一个表定义一个子缓存，如”TEST_ORDERS”，这里命名为 schema_tableName（tablename要大写），当有不少的根据主键查询SQL时，这个缓存每每须要设置比较大，才能更好的提高性能。

Mycat大数据量查询调优：

1.返回结果比较多

建议调整 frontWriteQueueSize 在系统许可的状况下加大，默认值*3

这个缘由是由于返回数据太多

这里作了一个改进，就是超过POOL之后，仍然建立临时的BUFFER供使用，但这些不回收。。   这样的状况下，须要增长BUFFER参数

调整 processorBufferPool = 默认值*2

不够的状况下，继续加大。

配置processors的具体大小。例如，配置processor的个数为16： server.xml文件中定义

<property name="processors">16</property>

    1

    1

还有一个要讨论的就是buffer pool。由于，全部的NIOProcessor共享一个buffer pool。
咱们在server.xml中提到过：
BufferPool的总长度 = bufferPool / bufferChunk
咱们能够链接到Mycat管理端口上，使用show @@processor命令列出全部的processor状态。
查看列： FREE_BUFFER、TOTAL_BUFFER、BU_PERCENT。
若是FREE_BUFFER的数值太小，则说明配置的buffer pool大小可能不够。这时候就要手动配置根据公式这个属性了，pool的大小最好是bufferChunk的整数倍。例如，配置buffer pool的大小为：5000 server.xml文件中定义

<property name="processorBufferPool">20480000</property>

    1

    1

另外一个buffer pool是线程内buffer pool，这个值能够根据processors的数值计算出来。具体看server.xml配置详解。

MySQL通用调优

首先MySQL要绝对避免使用Swap内存，网上有多种办法，能够参考。
这里是MySQL5.6及以上的调优参数，主要是提高多个database/table的写入和查询性能：
[mysqld]
当Order By 或者Group By等须要用到结果集时，参数中设置的临时表的大小小于结果集的大小时，就会将该表放在磁盘上，这个时候在硬盘上的IO要比内销差不少。所耗费的时间也多不少，mysql 会取min(tmp_table_size, max_heap_table_size)的值，所以两个设置为同样大小，除非是大量使用内存表的状况，此时max_heap_table_size要设置很大。
max_heap_table_size=200M
tmp_table_size=200M
下面这部分是Select查询结果集的缓存控制，query_cache_limit表示缓存的Select结果集的最大字节数，这个能够限制哪些结果集缓存，query_cache_min_res_unit表示结果集缓存的内存单元大小，若须要缓存的SQL结果集很小，好比返回几条记录的，则query_cache_min_res_unit越小，内存利用率越高，query_cache_size表示总共用多少
内存缓存Select结果集，query_cache_type则是控制是否开启结果集缓存，默认0不开启，1开启，2为程序控制方式缓存，好比SELECT SQL_CACHE …这个语句代表此查询SQL才会被缓存，对于执行频率比较高的一些查询SQL，进行指定方式的缓存，效果会最好。
FLUSH QUERY CACH命令则清理缓存，以更好的利用它的内存，但不会移除缓存，RESET QUERY CACHE 使命从查询缓存中移除全部的查询结果。

    #query_cache_type =1
    #query_cache_limit=102400
    #query_cache_size = 2147483648
    #query_cache_min_res_unit=1024

    1
    2
    3
    4

    1
    2
    3
    4

MySQL最大链接数，这个一般在1000-3000之间比较合适，根据系统硬件能力，须要对Linux打开的最大文件数作修改
max_connections =2100
下面这个参数是InnoDB最重要的参数，是缓存innodb表的索引，数据，插入数据时的缓冲，尽量的使用内存缓存，对于MySQL专用服务器，一般设置操做系统内存的70%-80%最佳，但须要注意几个问题，不能致使system的swap空间被占用，要考滤你的系统使用多少内存，其它应用使用的内在，还有你的DB有没有myisa引擎，最后减去这些才是合理的值。
innodb_buffer_pool_size=4G
innodb_additional_mem_pool_size除了缓存表数据和索引外,能够为操做所需的其余内部项分配缓存来提高InnoDB的性能。这些内存就能够经过此参数来分配。推荐此参数至少设置为2MB，实际上，是须要根据项目的InnoDB表的数目相应地增长
innodb_additional_mem_pool_size=16M
innodb_max_dirty_pages_pct值的争议，若是值过大，内存也很大或者服务器压力很大，那么效率很下降，若是设置的值太小，那么硬盘的压力会增长.
innodb_max_dirty_pages_pct=90
MyISAM表引擎的数据库会分别建立三个文件：表结构、表索引、表数据空间。咱们能够将某个数据库目录直接迁移到其余数据库也能够正常工做。然而当你使用InnoDB的时候，一切都变了。InnoDB 默认会将全部的数据库InnoDB引擎的表数据存储在一个共享空间中：ibdata1，这样就感受不爽，增删数据库的时候，ibdata1文件不会自动收缩，单个数据库的备份也将成为问题。一般只能将数据使用mysqldump 导出，而后再导入解决这个问题。innodb_file_per_table=1能够修改InnoDB为独立表空间模式，每一个数据库的每一个表都会生成一个数据空间。
独立表空间
优势：

    每一个表都有自已独立的表空间。
    每一个表的数据和索引都会存在自已的表空间中。
    能够实现单表在不一样的数据库中移动。
    空间能够回收（drop/truncate table方式操做表空间不能自动回收）
    对于使用独立表空间的表，无论怎么删除，表空间的碎片不会太严重的影响性能，并且还有机会处理。

缺点：

    单表增长比共享空间方式更大。

结论：
共享表空间在Insert操做上有一些优点，但在其它都没独立表空间表现好。
实际测试，当一个MySQL服务器做为Mycat分片表存储服务器使用的状况下，单独表空间的访问性能要大大好友共享表空间，所以强烈建议使用独立表空间。
当启用独立表空间时，因为打开文件数也随之增大，须要合理调整一下 innodb_open_files 、table_open_cache等参数。

    innodb_file_per_table=1
    innodb_open_files=1024
    table_open_cache=1024

    1
    2
    3

    1
    2
    3

Undo Log 是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用Undo Log来实现多版本并发控制(简称：MVCC)。Undo Log的原理很简单，为了知足事务的原子性，在操做任何数据以前，首先将数据备份到Undo Log，而后进行数据的修改。若是出现了错误或者用户执行了 ROLLBACK语句，系统能够利用Undo Log中的备份将数据恢复到事务开始以前的状态。所以Undo Log的IO性能对于数据插入或更新也是很重要的一个因素。因而，从MySQL 5.6.3开始，这里出现了重大优化机会：
As of MySQL 5.6.3, you can store InnoDB undo logs in one or more separate undo tablespaces outside of the system tablespace. This layout is different from the default configuration where the undo log is part of the system tablespace. The I/O patterns for the undo log make these tablespaces good candidates to move to SSD storage, while keeping the system tablespace on hard disk storage. innodb_rollback_segments参数在此被重命名为innodb_undo_logs
所以总共有3个控制参数：innodb_undo_tablespaces代表总共多少个undo表空间文件，innodb_undo_logs定义在一个事务中innodb使用的系统表空间中回滚段的个数。若是观察到同回滚日志有关的互斥争用，能够调整这个参数以优化性能，默认是128最大值，官方建议先设小，若发现竞争，再调大注意这里的参数是要安装MySQL时候初始化InnoDB引擎设置的，innodb_undo_tablespaces参数没法后期设定。
innodb_undo_tablespaces=128
innodb_undo_directory= SSD硬盘或者另一块硬盘，跟数据分开
innodb_undo_logs=64
下面是InnoDB的日志相关的优化选项
innodb_log_buffer_size这是 InnoDB 存储引擎的事务日志所使用的缓冲区。相似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提升性能，也是先将信息写入 Innofb Log Buffer 中，当知足 innodb_flush_log_trx_commit 参数所设置的相应条件(或者日志缓冲区写满)以后，才会将日志写到文件(或者同步到磁盘)中。innodb_log_buffer_size 不用太大，由于很快就会写入磁盘。innodb_flush_log_trx_commit的值有0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操做1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步; 2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操做。对于非关键交易型数据，采用2便可以知足高性能的日志操做，若要很是可靠的数据写入保证，则须要设置为1，此时每一个commit都致使一次磁盘同步，性能降低。
innodb_log_file_size此参数肯定数据日志文件的大小，以M为单位，更大的设置能够提升性能，但也会增长恢复故障数据库所需的时间。innodb_log_files_in_group分割多个日志文件，提高并行性。innodb_autoextend_increment对于大批量插入数据也是比较重要的优化参数（单位是M）

    innodb_log_buffer_size=16M
    innodb_log_file_size =256M
    innodb_log_files_in_group=8
    innodb_autoextend_increment=128
    innodb_flush_log_at_trx_commit=2
    #建议用GTID的并行复制，如下是须要主从复制的状况下，相关的设置参数。
    #gtid_mode = ON
    #binlog_format = mixed
    #enforce-gtid-consistency=true
    300
    #log-bin=binlog
    #log-slave-updates=true

文件简介：
server.xml：保存了有关MyCAT的配置信息，包括MyCAT对外暴露的schema（包含这个schema对应的帐户名和密码），MyCAT server的链接池等参数配置
cacheservice.properties：缓存区的配置

server.xml示例：

点击(此处)折叠或打开

    <?xml version="1.0" encoding="UTF-8"?>
    
    <!DOCTYPE mycat:server SYSTEM "server.dtd">
    <mycat:server xmlns:mycat="http://org.opencloudb/">
            <system>
            <property name="processors">32</property>
            <property name="processorExecutor">256</property>
            <property name="processorBufferPool">204800000</property>
            <property name="processorBufferChunk">40960</property>
                    
            <property name="maxStringLiteralLength">65535</property>
                    
                    
                    
                    
                    
            <property name="defaultSqlParser">druidparser</property>
            </system>
            
            <user name="test">
                    <property name="password">test</property>
                    <property name="schemas">test</property>
            </user>

            
            

    </mycat:server>

PS：MyCAT对外暴露的schema，是可使用readonly模式的，如上面配置文件中的加红部分；

processors：用于指定可用线程数，实际上因为如今的多核CPU和超线程技术，这个值能够酌情调高，这里调到了虚拟机核数的八倍，感受稍稍有点高了，实际上四倍or五倍就差很少了

processorExecutor：相似于线程池大小的参数，酌情修改便可，在1.4以后，这个线程池是用来作异步处理逻辑的时候用的，对并发能力的影响相对较小了

processorBufferPool：BufferPool的大小，原则上来讲，调高一些会比较好

processorBufferChunk：每个Buffer块的大小，processorBufferPool/processorBufferChun能够获得buffer块的数量

server调整总结：
processors+processorExecutor会影响到MyCAT可用的线程数，虽然调高点会比较好，可是调的过高会致使频繁的上下文切换和软中断，在实际调整中，用top观察sys和si的百分比，若是服务器/虚拟机并无什么不干净的后台程序和其余的服务在运行，sys在10%-15%以内，si在5%以内是比较理想的状态；

processorBufferPool+processorBufferChunk影响的server缓存，保持processorBufferChunk大小合理的状况下，增长buffer块的数量才是关键；

cacheservice.properties示例：

点击(此处)折叠或打开

    #used for mycat cache service conf
    factory.encache=org.opencloudb.cache.impl.EnchachePooFactory
    #key is pool name ,value is type,max size, expire seconds
    pool.SQLRouteCache=encache,1500000,60
    pool.ER_SQL2PARENTID=encache,2000,180
    layedpool.TableID2DataNodeCache=encache,3000,18000
    layedpool.TableID2DataNodeCache.TESTDB_ORDERS=10000,18000

cacheservice是SQL的缓存服务，

SQLRouteCache：sql路由缓存，经过缓存SQL语句的路由信息，下次查询，不用再路由了，直接从缓存中获取路由信息，而后发到各个节点执行；
TableID2DataNodeCache ：表主键ID的路由缓存，为每个表建一个缓存池，命名为TableID2DataNodeCache.TESTDB_表名,缓存的key是id的值，value是节点名；
ER_SQL2PARENTID ： ER关系的缓存目前只是在Insert语句中才会使用缓存，子表插入数据的时候，根据joinKey的值，判断父表所在分片，从而定位子表分片，分片信息put缓存，以便下次直接获取

因为在测试的时候并无对测试表是简单的区域划分，因此在测试中对后两个缓存是没有利用到的，具体对缓存大小的调整能够参考SQLRouteCache；

首先贴出结论：SQLRouteCache的大小对具体的QPS有比较大的影响（废话......._(:з」∠)_），在实际的测试过程当中，保持线程并发不变的状况下，从100W-300W都有调整过，大概每增长50W，有约15%的增长，直观来看的话,从100W-300W的增长过程当中，128线程，5张表x5000W行/表的状况下，QPS范围从1W5-2W5，然而有一个问题很重要，当这个值增长到比较高后，会频繁出现极高的sys占用率，同时vmstat命令下，proc列会有很是高的r和b，直接后果就是MyCAT server自己会出现剧烈的性能波动，在基准测试中，QPS的低谷会降到3000-4000；可是free查看内存使用的时候，并无出现内存不足的状况，推断为MyCAT自己的缓存设计中存在不完善的地方；

具体的设置值，在不断的测试中，以以前的虚拟机的配置（4核，32G）为参考，当SQLRouteCache的值设置到180W以上的时候，就会不定时的出现性能波动，为了保证稳定运行，在基准测试时采用了较低的150W

6.支持内存和外存并存的排序方式，结果集排序能够达上亿规模。此时应注意:

    a.此时前端和后端空闲链接超时检测时间应该设置大些，避免空闲检测关闭front或者backend
    connection,形成Mysqlclient链接丢失时结果集没法正确。
    b.设置-Xmn值尽量大些，新生代使用UseParallelGC垃圾回收器，-Xss设置512K比较合适，物理内存足够时，MaxDirectMemorySize尽量设置大些，能够加快结果集处理时间，

例如:

-Xmx1024m -Xmn512m -XX:MaxDirectMemorySize=2048m -Xss256k -XX:+UseParallelGC

3 processors属性
这个属性主要用于指定系统可用的线程数，默认值为机器CPU核心线程数。
主要影响processorBufferPool、processorBufferLocalPercent、processorExecutor属性。NIOProcessor的个数也是由这个属性定义的，因此调优的时候能够适当的调高这个属性。
4 processorBufferChunk属性
这个属性指定每次分配Socket Direct Buffer的大小，默认是4096个字节。这个属性也影响buffer pool的长度。若是一次性获取的数过大buffer不够用常常出现警告，则能够适当调大。
5 processorBufferPool属性
这个属性指定bufferPool计算比例值。因为每次执行NIO读、写操做都须要使用到buffer，系统初始化的时候会创建必定长度的buffer池来加快读、写的效率，减小创建buffer的时间。
Mycat中有两个主要的buffer池:
- BufferPool
- ThreadLocalPool
BufferPool由ThreadLocalPool组合而成，每次从BufferPool中获取buffer都会优先获取ThreadLocalPool中的buffer，未命中以后才会去获取BufferPool中的buffer。也就是说ThreadLocalPool是做为BufferPool的二级缓存，每一个线程内部本身使用的。固然，这其中还有一些限制条件须要线程的名字是由$_开头。然而，BufferPool上的buffer则是每一个NIOProcessor都共享的。
默认这个属性的值为：默认bufferChunkSize(4096) * processors属性 * 1000
BufferPool的总长度 = bufferPool / bufferChunk。
若bufferPool不是bufferChunk的整数倍，则总长度为前面计算得出的商 + 1
假设系统线程数为4，其余都为属性的默认值，则：
bufferPool ＝ 4096 * 4 * 1000
BufferPool的总长度 : 4000 = 16384000 / 4096
这里写图片描述
6 processorBufferLocalPercent属性
前面提到了ThreadLocalPool。这个属性就是用来控制分配这个pool的大小用的，但其也并非一个准确的值，也是一个比例值。这个属性默认值为100。
线程缓存百分比 = bufferLocalPercent / processors属性。
例如，系统能够同时运行4个线程，使用默认值，则根据公式每一个线程的百分比为25。最后根据这个百分比来计算出具体的ThreadLocalPool的长度公式以下：
ThreadLocalPool的长度 = 线程缓存百分比 * BufferPool长度 / 100
假设BufferPool的长度为 4000，其余保持默认值。
那么最后每一个线程创建上的ThreadLocalPool的长度为： 1000 = 25 * 4000 / 100
7 processorExecutor属性
这个属性主要用于指定NIOProcessor上共享的businessExecutor固定线程池大小。mycat在须要处理一些异步逻辑的时候会把任务提交到这个线程池中。新版本中这个链接池的使用频率不是很大了，能够设置一个较小的值。
8 sequnceHandlerType属性
指定使用Mycat全局序列的类型。0为本地文件方式，1为数据库方式，2为时间戳序列方式，3为分布式ZK ID生成器，4为zk递增id生成。
从1.6增长两种ZK的全局ID生成算法。

2 maxCon属性
指定每一个读写实例链接池的最大链接。也就是说，标签内嵌套的writeHost、readHost标签都会使用这个属性的值来实例化出链接池的最大链接数。
3 minCon属性
指定每一个读写实例链接池的最小链接，初始化链接池的大小。

Benchmark属性 Benchmark:mycat链接服务降级处理： benchmark 基准, 当前端的总体connection数达到基准值是, 对来自该帐户的请求开始拒绝链接，0或不设表示不限制例如

<property name="benchmark">1000</property>
---------------------
做者：u014180504
来源：CSDN
原文：https://blog.csdn.net/u014180504/article/details/76595247
版权声明：本文为博主原创文章，转载请附上博文连接！前端