作者：京东零售 董方酉

引言

应用健康度是反馈应用健康程度的指标，它将系统指标分类为基础资源、容器、应用、报警配置、链路这几项，收集了一系列系统应用的指标，并对指标进行打分。

应用健康度的每一项指标显示着系统在某一方面可能存在的隐患和安全问题；因此提高应用健康度对于系统监控具有重要意义。知其然需知其所以然，了解应用健康度中的指标背后的隐患，对于我们了解和提升系统安全性很有帮助。

笔者作为后端研发工程师，同时在推动组内应用健康度提高的同时，基于遇到的问题现象，结合应用健康度进行剖析，将逐一总结一系列应用健康度隐患剖析；

第一篇，我们来剖析下容易被人忽视的数据库时区设置项可能导致的隐患。

一、应用健康度检查项

数据库连接池配置中，通过解析源代码获取，支持 DBCP1.X，DBCP2.X，Ali Durid，HikariCP 四种连接池；配置监测有以下几项

风险示例如下图所示：

connectTimeout 、SocketTimeout 和 时区 三个指标是连接池数据源的 url 中解析得到, 如：mysql://xxx.jd.com:3358/jdddddb_0?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8&connectTimeout=1000&socketTimeout=3000&serverTimezone=Asia/Shanghai

其中，时区设置容易被人忽视；忽略设置会带来什么样的隐患呢？

二、遇到的问题

1、现象

在 2023 年 3 月 12 日（3 月的第二个周日），系统 UMP 监控报警，提示如下

2、问题原因

Mysql 驱动：mysql-connector-java 升级到 8 版本后。将数据库时间解析到 java 时间，需要获取数据库的时区。如果数据库连接中指定时区，则会用该时区，否则可能会使用系统时区

可通过 select @@time_zone 语句查询，如果返回 SYSTEM，则说明数据库没有设置时区，使用 select @@system_time_zone 语句可查询得出系统默认时区，为 CST。

CST 时区为美国中部时间，由于美国有夏令时和非夏令时

CST 非夏令时对应 UTC-06:00，夏令时对应 UTC-05:00 。

美国的夏令时，从每年 3 月第 2 个星期天凌晨开始，到每年 11 月第 1 个星期天凌晨结束。

以 2023 年为例:

夏令时开始时间调整前：2023 年 03 月 12 日星期日 02:00:00，时间向前拨一小时.

调整后：2023 年 03 月 12 日星期日 03:00:00

夏令时结束时间调整前：2023 年 11 月 05 日星期日 02:00:00，时间往回拨一小时.

调整后：2023 年 11 月 05 日星期日 01:00:00

这意味这:CST 没有 2023-03-12 02:00:00~2023-03-12 03:00:00 这个区间的时间。会有两个 2023-11-05 01:00:00~2023-11-05 02:00:00 区间的时间。

因此，在获取信息时会抛出“SQLException: HOUR_OF_DAY: 2 -＞ 3”异常。

3、修改方案

数据库连接地址中设置数据时区：serverTimezone=Asia/Shanghai

三、时间相关的其他隐患

1、据研究实验反馈，设置时区为默认时可能有性能问题，往往需要指定时区。

2、使用 timestamp 类型时需注意时间偏差：

timestamp 类型的时间范围 between '1970-01-01 00:00:01' and '2038-01-19 03:14:07'，超出这个范围则值记录为'0000-00-00 00:00:00'，该类型的一个重要特点就是保存的时间与时区密切相关，UTC(Universal Time Coordinated)标准，指的是经度 0 度上的标准时间，我国日常生活中时区以首都北京所处的东半球第 8 区为基准，统一使用东 8 区时间(俗称北京时间)，比 UTC 要早 8 个小时，时区设置也遵照此标准，因此对应过来 timestamp 的时间范围则应校准为'1970-01-01 08:00:01' and '2038-01-19 11:14:07'，也就是说东八区的 1970-1-1 08:00:01 等同于 UTC1970-1-1 00:00:01。

3、尽量使用 dateTime 格式而非 timestamp:

有一些情况需要注意不要使用 timestamp 存储时间：

• 生日：生日肯定会有早于 1970 年的，会超出 timestamp 的范围

• 有效期截止时间：timestamp 的最大时间是 2038 年，如果用来存类似身份证的有效期截止时间，营业执照的截止时间等就不合适。

• 业务生存时间：互联网时代发展快，业务时间很可能在 2038 年还在继续运营。

四、数据库连接设置的其他隐患

1、连接数设置

(1) 介绍

数据库连接池在初始化时将创建一定数量的数据库连接放到连接池中，这些数据库连接的数量是由最小数据库连接数制约。无论这些数据库连接是否被使用，连接池都将一直保证至少拥有这么多的连接数量。连接池的最大数据库连接数量限定了这个连接池能占有的最大连接数，当应用程序向连接池请求的连接数超过最大连接数量时，这些请求将被加入到等待队列中。

由此看来，当数据库最大连接数设置不够大时，则会出现某些报表或需要查询数据库的请求失败，由于连接数不够不能被处理，从而报错。当出现大量并发的报表请求，且连接池的最大连接数不够用时，一些用户的请求就无法处理，这样也就从另一个层面影响了整个项目处理吞吐量的能力，限制了项目的性能和效率。

(2)设置原则

既能保证项目正常使用时对数据库连接数的要求，又能保护 DBS 的安全和稳定。

(3)查询方式：

查询最大连接数命令：show variables like'%max_connections%';

查询当前数据库已建立连接数：show status like 'Threads_connected';

(4)建议：

MYSQL 官网给出了一个设置最大连接数的建议比例：

Max_used_connections / max_connections * 100% ≈ 85%

即已使用的连接数占总上限的 85%左右。

2、超时时间设置

(1)介绍

一次完整的请求包括三个阶段：1、建立连接 2、数据传输 3、断开连接

connect timeout:如果与服务器(这里指数据库)请求建立连接的时间超过 ConnectionTimeOut，就会抛 ConnectionTimeOutException，即服务器连接超时，没有在规定的时间内建立连接。 在数据库连接设置中，connectTimeout 表示等待和 MySQL 数据库建立 socket 链接的超时时间，默认值 0，表示不设置超时，单位毫秒。

socket timeout:如果与服务器连接成功，就开始数据传输了。如果服务器处理数据用时过长，超过了 SocketTimeOut，就会抛出 SocketTimeOutExceptin，即服务器响应超时，服务器没有在规定的时间内返回给客户端数据。在数据库连接设置中，socketTimeout 表示客户端和 MySQL 数据库建立 socket 后，读写 socket 时的等待的超时时间，linux 系统默认的 socketTimeout 为 30 分钟。

（2）隐患

访问数据库超时间太长，访问数据量大或者扫描的数据量太大，导致数据库长时间无响应。链接被占用无法释放，会导致线程池被占满。因此，为了能够及时释放占用链接，其他业务对数据库访问不受影响，所以要合理设置数据库访问超时时间。

JDBC 的 socket timeout 在数据库被突然停掉或是发生网络错误（由于设备故障等原因）时十分重要。由于 TCP/IP 的结构原因，socket 没有办法探测到网络错误，因此应用也无法主动发现数据库连接断开。如果没有设置 socket timeout 的话，应用在数据库返回结果前会无期限地等下去，这种连接被称为 dead connection。

为了避免 dead connections，socket 必须要有超时配置。socket timeout 可以通过 JDBC 设置，socket timeout 能够避免应用在发生网络错误时产生无休止等待的情况，缩短服务失效的时间。

（3）建议

一般情况，建议配置 connectTimeout=60000，单位毫秒。建议配置 socketTimeout=60000，单位毫秒。具体配置因系统而异。

总结

容易被忽视的数据库连接应用健康度检查项，背后有着时区、超时时间、连接数设置不当可能带来的隐患；根据应用实际情况并遵循设置原则进行合理设置，满足应用健康度检查项，才能防患于未然。