这是学习笔记的第 1931 篇文章
今天对一个MyCAT集群做了下优化，经过反复调试，也算是有一个初步的改进。
在业务层面的改进还需要继续做下确认。单从系统层面来看，效果还是比较明显的。
整个问题的背景是业务经过分片改造，对一些大表完成了拆分，比如一个大表有4亿记录，为了控制单表的粒度，我们把它拆为了400份，那么一份只有100万条记录，当然从目前使用MyCAT分片的方式来看，400个分片需要的是400个数据库，也就是有400个节点的配置信息，如果配置了多张表，这个复杂度会大大增强。
可以打个比方，本来一张表的复杂度为400N,但是如果是10张这样的表，这个复杂度就是400*N*10，所以从这个角度来看，这也算是分布式的方式带来的一种额外代价。
目前的系统碰到的问题类似这种，因为在写入的时候会有主键冲突，会造成数据的写入失败，对中间件的性能会有毛刺和抖动，同时QPS总量在2万左右，其中的的读请求占据80%~90%，大批量的请求处理的过程中，对于路由的复杂度就是一种新的挑战，在部分表的查询中已经出现了延迟的情况，随着业务测试压力的加大，这个问题会变得更加明显，直到从业务层面基础的指标无法达成。所以中间件的优化也是在这种情况下的应需而动。
整个优化的过程持续了多次，以下是一个性能的对比图，之前的高峰时间，一个分片节点的系统负载在35左右，经过优化之后的负载高峰时段维持在5左右。
从系统上线的标准来看，明显还是过高，因为是做压力测试，后续的业务上线肯定还要做服务的拆分，通过把瓶颈问题的定位和分析把潜在问题先解决掉。
JVM参数优化：
首先优化的部分是JVM,之前的缓存设置是取默认值，对于这个业务场景来说，明显太低了，所以调整为4G.
否则会容易产生GC的溢出，类似如下的错误内容。
INFO | jvm 3 | 2019/03/27 12:10:55 | 2019-03-27 12:09:53,295 [ERROR][$_NIOREACTOR-1-RW] caught err: java.lang.OutOfMemoryError: GC overhead limit exceeded
对于一个线上的业务支撑来说，这是很不应该的了。
连接数配置改进
schema.xml里面的配置类似下面的方式：
<dataHost name="localhost1" maxCon="1000" minCon="10" balance="0"
其实在运行中不断地创建线程回收，上下文的频繁切换会导致整个系统的性能负载变大，所以可以把默认的连接池配置放大，比如按照目前的配置，我改为了如下的方式：
<dataHost name="localhost1" maxCon="1000" minCon="500" balance="0"
路由缓存改进
其中还有一个重点的内容，就是路由的复杂度问题，这个负载度如果通过缓存能够缓解是极好的。
cache.properties的配置信息如下，默认是1000，
pool.SQLRouteCache=encache,1000,1800
通过9066的管理入口，使用命令show @@cache查看，发现命中率其实还是不高，以下是初步调整为10000时的cache情况。
所以有了这个基本的数据，也可以基本理解整个分片节点的性能低的原因了，中间件通过路由算法定位对象，但是定位的操作延迟，会导致整个分片节点的交互中响应也会产生延迟，这种延迟不是系统资源繁忙，而是主要因为系统等待。
经过初步的改造，调整为100万，虽然这种方式的改进效果还待商榷，总体来看效果比原来要好很多了。
pool.SQLRouteCache=encache,1000000,1800
当然我们做分布式方案，本质上不是单纯把所有资源都集中管理起来，分布式方案有它自己的优势，也有它所不擅长的方向和领域，从业务规划的角度来说，我们可以细挖一些场景和需求，把目前碰到的硬骨头问题化解之后通过迭代的改进方式进行梳理。