分片检测超时故障分析和复盘
概述
在新建Schema时，当分片数设为128个分片时报504错误，分片较少时正常。经走查日志、排查机器网络环境、查看代码子模块运行耗时等过程，确定为由于zookeeper跨AZ、部分节点时延高导致的异常。
故障问题解决方案：在配置库中剔除时延高的zookeeper节点，管控平台只与时延低的zookeeper节点交互，此后分片检测正常。
问题详情
客户的问题较为明确，即创建schema时分片较少时正常，分片数较多时检测异常。
当前客户是单个实例关联了8个RDS实例。
当分片数较少时，检测正常通过
当分片数较多时，每个RDS实例创建16个分片，总共128个分片，检测失败，报504 GateWay Timeout的错误。
问题分析
首先，明确下RDS分片检测的过程逻辑，
RDS分片检测可分为三个过程，(1)检查schema名称是否重复的预处理 (2) 连接zk，检查分片名，n个分片就需要与zookeeper交互n次; (3) 多线程并发去底层查询是否有同名schema
其次，在了解上述执行过程的基础上，分析程序的模块执行耗时。
- 查看zookeeper的耗时情况，耗时72秒，远远超过正常的交互时间。
- 查看底层dn查询的耗时情况，耗时3秒，执行情况正常
至此，初步定位至管控平台与zookeeper网络导致的异常。
通过查看管控平台查询zookeeper的queryForMapList函数，确定zookeeper集群内部存在耗时差异很大的情况，由于zookeeper是三节点集群，会随机选取一个节点进行交互，故单个zookeper节点时延长会导致整体查询耗时长，最终导致超时的问题。
进一步地，验证机器与zookeeper的时延情况，
发现确实存在172.25.xx.xx节点的时延极高，与其他同集群节点相差数十倍。
解决方案
针对部分zookeeper节点时延高的情况，可以修改配置库，使管控平台与时延低的zookeeper节点交互。
具体操作步骤为：
1、找到管控平台的配置库，查看application.yml配置文件的spring.datasource信息
2、登录配置库，查看zookeeper_info表
3、修改配置库，只保留时延低的zookeeper节点
4、 重启控制台。
验证：修改后，检测通过，一切正常
- 还原配置库的zookeeper_info表，并重启控制台。
注：此处还原的前提是用户建立大数量分片（128个）成功，并且此后不频繁创建大数量分片。如果频繁的话，本质上还是要从网络层面解决zk时延高的节点。
附录
补充下Arthas工具的基本使用。
Arthas 是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率。
- 启动Arthas,进入交互界面
java -jar arthas-boot.jar
选择目标应用 java 进程，此处为控制台程序
- 查看进程信息
输入dashboard
- monitor查看具体方法的执行监控，调用次数、执行时间、失败率的信息。
例如，调用栈为com.cloud.udal.admin.service.cfg.impl.SchemaServiceImpl#checkDatabasesValid
monitor 类路径 类方法名称
输入 monitor com.cloud.udal.admin.dao.common.IBaseZkDao queryForMapList ，查看查询单次zookeeper的耗时
- quit/exit退出当前连接；stop退出arthas程序
如果只是退出当前的连接，可以用quit或者exit命令。Attach 到目标进程上的 arthas 还会继续运行，端口会保持开放，下次连接时可以直接连接上。
如果想完全退出 arthas，可以执行stop命令。
