背景

大数据平台一般的技术栈，是使用HDFS作为数据存储系统，使用YARN作为资源管理器，使用Spark作为执行引擎。

Spark提供的其中一个组件是Thrift Server。启动Thrift Server之后，将作为常驻任务在YARN上运行，通过JDBC协议我们可以连接Thrift Server，创建连接对象（连接池），并执行合法的sql语句。这种感觉跟连接一般的关系型数据库很像。

Thrift Server作为YARN上的常驻任务，可以通过YARN的管理界面找到该任务的记录，然后通过Tracking UI进入spark的Application Master界面：

1574333028879.png

1574333076272.png

在这里你可以看到Thrift Server执行的SQL，分析每一条sql执行所花费的时间。在做性能测试和调优的时候，有很大的作用。

问题就是我们在这里看到很多的SELECT 1语句，而且每几秒就会吐出1条或多条SELECT 1，关键的SQL语句很快被刷屏冲掉了。

P.S. 现在大家所看到的截图是修复后的版本，所以没有SELECT 1了。

分析

因为我们使用了druid作为连接池的实现，一开始怀疑是druid在做连接有效性检测。最初的时候，我们将怀疑的范围锁定在下面的配置上：

spring:
  datasource:
    druid:
      validation-query: SELECT 1
      test-while-idle: true
      test-on-borrow: true
      test-on-return: true

通过将三个tes-*配置项都改为false，然后进行测试，发现还是在不停的吐出SELECT 1。

然后，我们将validation-query改成SELECT 'di-sql-engine'，以确认不停吐出的SELECT 1是否由配置所引起的，然后发现还是每隔5秒吐出一次SELECT 1。并且每隔一分钟会连续吐出多个SELECT 'di-sql-engine'。

我决定先排查为什么还会吐出SELECT 'di-sql-engine'的问题，从validation-query配置项查起，先找到哪个类里面定义了这个配置项：

1574390820285.png

最终，我们找到了声明validation-query配置项的类：DruidAbstractDataSource。

进一步，我们在这个类查找哪个方法使用了这个属性，我们定位到下面的方法：

public void validateConnection(Connection conn) throws SQLException {}

在这个方法里使用了这个配置项，如果该配置项的值不为null，就会执行这条sql。所以，我们可以不配置validation-query，因为它默认的值是null。

这个方法，只是简单的执行，并没有判断是否需要执行的逻辑（比如根据上述test-*配置项，判断是否需要执行）。进一步推测，判断的逻辑应该在上层，继续寻找调用了这个方法的上层方法。

在类DruidDataSource找到下面的方法，有调用目标的方法：

public void shrink(boolean checkTime, boolean keepAlive)

分析这个方法，得到的结论是，druid会判断keepAlive的配置，如果该配置项为true，就会针对每一个空闲时间超过keepAliveBetweenTimeMillis的连接对象进行存活性的检测（即调用上面的validateConnection方法）。

退回来查看配置文件，发现下面的配置：

spring:
  datasource:
    druid:
      keep-alive: true

所以，我们会发现下面的现象：

并且每隔一分钟会连续吐出多个SELECT 'di-sql-engine'。

这是因为每隔一分钟会执行一次shrink，每一次执行都会针对每一个空闲时间超过设定值的连接进行存活性判断，相当于连续发送多次validateConnection。

至此，我们找到解决这个问题的方法，不要配置keep-alive（因为默认值为false），或者不要配置validation-query（默认值为null）。

但是鉴于健壮性的考虑，我们选择将keepAliveBetweenTimeMillis的时间间隔增大，由原来的默认1分钟改为10分钟。

至此，我们解决2个问题中的其中1个，接下来我们要分析为什么每隔5秒会有一个SELECT 1吐出来。

静态代码分析已经获取不到更多的线索了，我们采用debug的手段，在本机启动服务，在DruidDataSource类的获取连接的方法上打断点：

1574394144034.png

不管SELECT 1是谁发起执行的，总需要获取连接吧，就在这里断点好了。

在捕获断点之后，我们分析它的调用栈，首先追踪到这个位置：

1574394179013.png

我们看到JdbcTemplate在调用，但是具体执行的sql语句我们还需要继续往上追踪（即ConnectionCallback的具体实现）。

接下来我们追踪到下面的位置：

1574394285915.png

到这里，我们已经可以看到具体的执行语句的出处了，它来自getValidationQuery方法。我们继续查看这个方法的内容：

1574394332013.png

最终，我们看到了熟悉的语句：SELECT 1。

看看这个类，类名中包含了Health，属于spring-boot-actuator。所以它应该与spring-boot-actuator提供的健康检查功能有关。

网上查找资料，如何取消db数据库的健康状态检查，我们得到下面的配置项：

1574394489299.png

我们可以看到，其默认值为true，其作用为："Whether to enable database health check."。将配置改为false，重启服务，发现已经没有5秒一次的SELECT 1了。

结论

当我们使用jdbc连接spark-thriftserver时，因为spark提供了application界面，我们可以看到thrift server执行的sql语句。

druid有定时检测连接有效性的机制，相关的配置项如下所示：

validationQuery
用来检测连接是否有效的sql，要求是一个查询语句。如果validationQuery为null，testOnBorrow、testOnReturn、 testWhileIdle都不会其作用。
testWhileIdle
建议配置为true，不影响性能，并且保证安全性。申请连接的时候检测，如果空闲时间大于 timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效。
testOnBorrow
申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
testOnReturn
归还连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
keepAlive
定期检查连接是否有效，无效的连接将被close。
keepAliveBetweenTimeMillis
keepAlive相关的时间配置，一个连接在keepAliveBetweenTimeMillis时间范围内，不会被多次检查

下面给出在连接Spark Thrift Server场景下的建议配置，其中keepAliveBetweenTimeMillis设置为10分钟：

spring:
  datasource:
    druid:
      keep-alive: true
      keep-alive-between-time-millis: 600000
      validation-query: SELECT 'di-sql-engine'
      test-while-idle: false
      test-on-borrow: false
      test-on-return: false

spring-boot-actuator的健康状态检查机制，包含了对数据库的检查。因为没有找到健康检查周期频率的可配置项，所以大家根据需要看看是否关闭数据库的健康检查：

management:
  health:
    db:
      enabled: false

Spark Thrift Server收到太多的SELECT 1

Spark Thrift Server收到太多的SELECT 1

背景

分析

结论