应用健康度隐患刨析解决系列之数据库时区设置

作者：京东零售 董方酉

引言

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

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

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

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

一、应用健康度检查项

数据库连接池配置中，通过解析源代码获取，支持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，单位毫秒。具体配置因系统而异。

总结

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