봄 부팅 2.x를 기준 : 국내 데이터베이스 연결 풀 드루이드의 사용

하나 , 우리는 기본 데이터 소스 HikariCP를 사용하여 JDBC 모듈 자동화 된 구성에서 봄 부팅을 소개했다. 그런 다음이 섹션에서는, 우리는 또 다른 널리 사용되는 오픈 소스 데이터 소스를 소개합니다 : 드루이드를.

드루이드는 알리바바 부문 데이터베이스 오픈 소스 프로젝트에 의해 생산된다. 또한 그것은, 고성능 데이터베이스 연결 풀 수있는 데이터베이스 연결 풀 모니터링을 수행하고있다. HikariCP 아주 좋은되었지만,하지만 국내 사용자를 위해, 드루이드 더 잘 알고있을 수 있습니다. 그래서, 봄 부팅에서 드루이드를 사용하는 방법에 대해 기본적인 기술을 마스터 개발자가 필요 백엔드입니다.

사제 구성된 데이터 소스

우리가 기반으로이 섹션 연습 "JdbcTemplate을 사용하여 액세스 MySQL 데이터베이스에 봄 부팅 2.x를 기반 튜토리얼": 텍스트에 근거하여 코드를. 그래서 독자는 텍스트, 검출의 끝에서 저장소를 코딩 할 수 있습니다 chapter3-1다음과 같은 실제적인 학습을위한 디렉토리.

여기에서 우리는 봄 부팅 드루이드 프로젝트에 대한 데이터 소스 구성을 시작해야합니다 :

첫 번째 단계는 다음 pom.xml봄 부팅 스타터 패키지의 도입은 공식 서비스를 드루이드.

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>druid-spring-boot-starter</artifactId>
    <version>1.1.21</version>
</dependency>
复制代码

두 단계 :에서 application.properties구성 데이터베이스에서 연결 정보를 표시합니다.

사제가 배치되어 spring.datasource.druid프리픽스 구성은 이전에있어서, 약간 수정 :

spring.datasource.druid.url=jdbc:mysql://localhost:3306/test
spring.datasource.druid.username=root
spring.datasource.druid.password=
spring.datasource.druid.driver-class-name=com.mysql.cj.jdbc.Driver
复制代码

세 번째 단계 : 드루이드 연결 풀 구성.

데이터 소스가 좋은를 사용하는 것처럼 그리고 히카리, 우리는 다음과 같은 자사의 연결 풀의 적절한 구성해야합니다 :

spring.datasource.druid.initialSize=10
spring.datasource.druid.maxActive=20
spring.datasource.druid.maxWait=60000
spring.datasource.druid.minIdle=1
spring.datasource.druid.timeBetweenEvictionRunsMillis=60000
spring.datasource.druid.minEvictableIdleTimeMillis=300000
spring.datasource.druid.testWhileIdle=true
spring.datasource.druid.testOnBorrow=true
spring.datasource.druid.testOnReturn=false
spring.datasource.druid.poolPreparedStatements=true
spring.datasource.druid.maxOpenPreparedStatements=20
spring.datasource.druid.validationQuery=SELECT 1
spring.datasource.druid.validation-query-timeout=500
spring.datasource.druid.filters=stat
复制代码

드루이드는 다음 표에서 찾을 수 있습니다 각 연결 풀 구성에 대한 설명 :

구성	기본값	설명
이름		이 속성의 의미를 구성하는 여러 데이터 소스를 모니터링 할 수있는 경우는 지역 이름으로 구별 할 수있을 때이다. 어떤 경우에 이름을 생성하는 것, 형식은 :. "DataSource-"+ System.identityHashCode ( 본) 이 속성이 별도로 1.0.5 버전이 비활성 적어도 배치되어, 오류가 강제적으로 설정된 이름이어야한다. 세부 사항 - 여기를 클릭 .
URL		데이터베이스에 URL 연결은 다른 데이터베이스는 동일하지 않습니다. 예를 들어 MySQL의 : JDBC : mysql을 : //10.20.153.104 : 3306 / druid2 오라클 : JDBC : 신탁 : 얇은 : 10.20.149.85 @ : 1521 : ocnauto
사용자 이름		사용자 이름은 데이터베이스를 연결하는
암호		데이터베이스 연결을위한 암호입니다. 구성 파일에서 직접 코드를 작성하지 않으려면 ConfigFilter를 사용할 수 있습니다. 자세한 것은 이쪽을 봐주세요
driverClassName	자동 인식 URL	이 기능은 자동으로 DBTYPE URL을 식별 드루이드 구성을 기반으로하지 않은 경우 가치가, 다음, 적절한 driverClassName을 선택할 수 있습니다
initialSize가	0	물리적 연결 초기화의 수를 설립. 디스플레이 초기화 방법, 또는 제 1의 getConnection를 호출 할 때 발생하는 초기화
maxActive	8	연결 풀의 최대 수
maxIdle	8	그것은 더 이상 아무런 영향을 갖추고, 사용되지 않습니다
minIdle		연결 풀의 최소 번호
maxWait		최대 대기 시간 (밀리 초)에 연결되어 가져옵니다. 필요한 경우 기본 공정 잠금으로 설정 maxWait을 구성한 후, 동시 효율 사실 불공정 잠금으로 구성 useUnfairLock 속성을 사용하여, 감소 할 것이다.
poolPreparedStatements	그릇된	PSCache 한 캐시 PreparedStatement의 여부. PSCache 지원 데이터베이스는 예를 들어 오라클에 대한 엄청난 성능 향상을, 커서. mysql을의 제안 폐쇄에서.
maxPoolPreparedStatementPerConnectionSize	-1	0보다 큰 poolPreparedStatements이 자동으로 true로 변경 트리거 될 때 PSCache을 사용하려면 0보다 큰 구성을해야합니다. 사제에서 PSCache는 오라클 문제가 너무 많은 메모리가없는 경우이 값은 100로, 크게 구성 될 수있다
validationQuery		유효한 연결 SQL 여부를 검출를 들어, 쿼리가 'X', 일반적인 선택이 필요합니다. validationQuery는 널 (null), testOnBorrow, testOnReturn, testWhileIdle는하지 않습니다 일 경우.
validationQueryTimeout		단위 : 올바른 연결 초과하는지 제 2 검출. 무효 setQueryTimeout 레벨이 JDBC Statement 오브젝트 (INT 초)를 호출 방법
testOnBorrow	진실	실행 validationQuery 연결을 신청,이 구성은 성능이 저하 될 수 있습니다했을 때 연결이 유효한지 여부를 감지합니다.
testOnReturn	그릇된	반환 된 접속 유효 실행 validationQuery이 구성은 성능을 저하시킬 수에 대한 접속을 검출한다.
testWhileIdle	그릇된	권장 구성은 성능에 영향을, 그리고 안전을 보장하지 않는 사실이다. 유휴 시간 timeBetweenEvictionRunsMillis보다 크면 응용 연결, 연결 validationQuery 검출 수행이 유효한 때를 검출.
살아 유지	거짓 (1.0.28)	유휴 시간 minEvictableIdleTimeMillis의 minIdle 연결 풀에서 연결 수, 연결 유지 작업이 실행됩니다.
timeBetweenEvictionRunsMillis	1 분 동안 (1.0.14)	연결 대기 시간보다 크거나 minEvictableIdleTimeMillis 물리적 연결을 종료 동일하면 1) 검출 간격 스레드 연결 처치 : 그것은 두 가지 의미를 갖는다. 2) testWhileIdle 판정 기준, 속성 testWhileIdle의 상세한 설명을 참조
numTestsPerEvictionRun	30분 (1.0.14)	不再使用，一个DruidDataSource只支持一个EvictionRun
minEvictableIdleTimeMillis		连接保持空闲而不被驱逐的最小时间
connectionInitSqls		物理连接初始化的时候执行的sql
exceptionSorter	根据dbType自动识别	当数据库抛出一些不可恢复的异常时，抛弃连接
filters		属性类型是字符串，通过别名的方式配置扩展插件，常用的插件有： 监控统计用的filter:stat 日志用的filter:log4j 防御sql注入的filter:wall
proxyFilters		类型是List<com.alibaba.druid.filter.Filter>，如果同时配置了filters和proxyFilters，是组合关系，并非替换关系

到这一步，就已经完成了将Spring Boot的默认数据源HikariCP切换到Druid的所有操作。

配置Druid监控

既然用了Druid，那么对于Druid的监控功能怎么能不用一下呢？下面就来再进一步做一些配置，来启用Druid的监控。

第一步：在pom.xml中引入spring-boot-starter-actuator模块

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
复制代码

第二步：在application.properties中添加Druid的监控配置。

spring.datasource.druid.stat-view-servlet.enabled=true
spring.datasource.druid.stat-view-servlet.url-pattern=/druid/*
spring.datasource.druid.stat-view-servlet.reset-enable=true
spring.datasource.druid.stat-view-servlet.login-username=admin
spring.datasource.druid.stat-view-servlet.login-password=admin
复制代码

上面的配置主要用于开启stat监控统计的界面以及监控内容的相关配置，具体释意如下：

• spring.datasource.druid.stat-view-servlet.url-pattern：访问地址规则
• spring.datasource.druid.stat-view-servlet.reset-enable：是否允许清空统计数据
• spring.datasource.druid.stat-view-servlet.login-username：监控页面的登录账户
• spring.datasource.druid.stat-view-servlet.login-password：监控页面的登录密码

第三步：针对之前实现的UserService内容，我们创建一个Controller来通过接口去调用数据访问操作：

@Data
@AllArgsConstructor
@RestController
public class UserController {

    private UserService userService;

    @PostMapping("/user")
    public int create(@RequestBody User user) {
        return userService.create(user.getName(), user.getAge());
    }

    @GetMapping("/user/{name}")
    public List<User> getByName(@PathVariable String name) {
        return userService.getByName(name);
    }

    @DeleteMapping("/user/{name}")
    public int deleteByName(@PathVariable String name) {
        return userService.deleteByName(name);
    }

    @GetMapping("/user/count")
    public int getAllUsers() {
        return userService.getAllUsers();
    }

    @DeleteMapping("/user/all")
    public int deleteAllUsers() {
        return userService.deleteAllUsers();
    }

}
复制代码

第四步：完成上面所有配置之后，启动应用，访问Druid的监控页面http://localhost:8080/druid/，可以看到如下登录页面：

输入上面spring.datasource.druid.stat-view-servlet.login-username和spring.datasource.druid.stat-view-servlet.login-password配置的登录账户与密码，就能看到如下监控页面：

进入到这边时候，就可以看到对于应用端而言的各种监控数据了。这里讲解几个最为常用的监控页面：

数据源：这里可以看到之前我们配置的数据库连接池信息以及当前使用情况的各种指标。

SQL监控：该数据源中执行的SQL语句极其统计数据。在这个页面上，我们可以很方便的看到当前这个Spring Boot都执行过哪些SQL，这些SQL的执行频率和执行效率也都可以清晰的看到。如果你这里没看到什么数据？别忘了我们之前创建了一个Controller，用这些接口可以触发UserService对数据库的操作。所以，这里我们可以通过调用接口的方式去触发一些操作，这样SQL监控页面就会产生一些数据：

图中监控项上，执行时间、读取行数、更新行数都通过区间分布的方式表示，将耗时分布成8个区间：

• 0 - 1 耗时0到1毫秒的次数
• 1 - 10 耗时1到10毫秒的次数
• 10 - 100 耗时10到100毫秒的次数
• 100 - 1,000 耗时100到1000毫秒的次数
• 1,000 - 10,000 耗时1到10秒的次数
• 10,000 - 100,000 耗时10到100秒的次数
• 100,000 - 1,000,000 耗时100到1000秒的次数
• 1,000,000 - 耗时1000秒以上的次数

记录耗时区间的发生次数，通过区分分布，可以很方便看出SQL运行的极好、普通和极差的分布。 耗时区分分布提供了“执行+RS时分布”，是将执行时间+ResultSet持有时间合并监控，这个能方便诊断返回行数过多的查询。

SQL防火墙：该页面记录了与SQL监控不同维度的监控数据，更多用于对表访问维度、SQL防御维度的统计。

该功能数据记录的统计需要在spring.datasource.druid.filters中增加wall属性才会进行记录统计，比如这样：

spring.datasource.druid.filters=stat,wall
复制代码

注意：这里的所有监控信息是对这个应用实例的数据源而言的，而并不是数据库全局层面的，可以视为应用层的监控，不可能作为中间件层的监控。

代码示例

本文的相关例子可以查看下面仓库中的chapter3-3目录：

• Github：github.com/dyc87112/Sp…
• Gitee：gitee.com/didispace/S…

如果您觉得本文不错，欢迎Star支持，您的关注是我坚持的动力！

欢迎关注我的公众号：程序猿DD，获得独家整理的学习资源和日常干货推送。 如果您对我的专题内容感兴趣，也可以关注我的博客：didispace.com