线上系统时间慢八个小时的排查之路-优快云博客

👉 这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：

《项目实战（视频）》：从书中学，往事上“练”
《互联网高频面试题》：面朝简历学习，春暖花开
《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题
《精进 Java 学习指南》：系统学习，互联网主流技术栈
《必读 Java 源码专栏》：知其然，知其所以然

👉这是一个或许对你有用的开源项目

国产 Star 破 10w+ 的开源项目，前端包括管理后台 + 微信小程序，后端支持单体和微服务架构。

功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号等等功能：

Boot 地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro
Cloud 地址：https://gitee.com/zhijiantianya/yudao-cloud
视频教程：https://doc.iocoder.cn

来源：juejin.cn/post/
7221740907232657468

最近有一个新项目上线，在上线时，突然发现时间与正常时间对不上，少了八个小时；但我丝毫不慌，这不就是个时区的问题吗，简单，但是这一次它给我深深的上了一课，一起来看整个排查过程吧。

开始排查

排查数据库

一般的时区问题都是数据库配置或数据链接参数的配置问题，于是我立马就定位到了问题，应该是数据库的时区设置错了，于是我愉快的查看了数据库时区

❝

命令：show variables like '%time_zone%';

❞

1、system_time_zone：全局参数，系统时区，在MySQL启动时会检查当前系统的时区并根据系统时区设置全局参数system_time_zone的值。值为CST，与系统时间的时区一致。

2、time_zone：全局参数，设置每个连接会话的时区，默认为SYSTEM，使用全局参数system_time_zone的值。

CST时间

CST时间：中央标准时间。CST可以代表如下4个不同的时区：

Central Standard Time (USA) UT-6:00，美国
Central Standard Time (Australia) UT+9:30，澳大利亚
China Standard Time UT+8:00，中国
Cuba Standard Time UT-4:00，古巴

再次分析

很显然，这里与UTC时间无关，它只是时间标准。目前Mysql中的system_time_zone是CST，而CST可以代表4个不同的时区，那么，Mysql把它当做哪个时区进行处理了呢？

简单推算一下，中国时间是UT+8:00，美国是 UT-6:00，当传入中国时间，直接转换为美国时间（未考虑时区问题），时间便慢了14个小时。

既然知道了问题，那么解决方案也就有了。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/

解决方案

方案一：修改数据库时区

既然是Mysql理解错了CST指定的时区，那么就将其设置为正确的。

连接Mysql数据库，设置正确的时区：

set global time_zone = '+8:00';
set time_zone = '+8:00';
flush privileges;

再次执行show命令查看：show variables like '%time\_zone%';。

这里我选择方案2：修改数据库连接参数

> 基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
>
> * 项目地址：<https://github.com/YunaiV/yudao-cloud>
> * 视频教程：<https://doc.iocoder.cn/video/>

# 原配置
serverTimezone=GMT%2B8
##修改 serverTimezone=Asia/Shanghai 

url: jdbc:mysql://localhost:3306/aurora_admin?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=Asia/Shanghai&autoReconnect=true&rewriteBatchedStatements=true&allowMultiQueries=true

到这里，我想着问题肯定已经解决了；愉快的测了一手；结果还是差八个小时？但是本地项目的时间是正常的啊，我开始有了不祥的预感; 于是我本地连上线上的数据库开始测试，发现时间是正常的。到这里，就基本排查出不是MySQL的问题。

排查 Linux

我开始怀疑是不是 linux 系统的时区有问题；

❝

查看硬件的时间：hwclock --show

❞

❝

查看系统的时间：date -R

❞

发现Linux的时间四年没问题的，于是开始查服务器的时区配置查看时区 TZ配置：echo $TZ

发现为空，于是查看系统配置；查看系统配置命令：env

发现确实没有 TZ 的配置，系统并未设置TZ变量，而是通过localtime指定时区；于是我修改 localtime的指定。

❝

先删除TZ环境变量：unset TZ

❞

❝

再执行：ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 命令etc目录下创建名称是localtime的快捷键指定到上海时区文件上；

❞

修改完成后，果断重启项目测试，结果令人失望，时间依旧没有变化，于是尝试直接加上 TZ配置

❝

命令：export TZ=Asia/Shanghai

❞

再次查看：

可以看到 TZ配置已经设置成功，到这里我似乎看到了希望；于是再次测试，然后我人傻了，时间依旧少八个小时；到这里，我实在是不知道还有什么是没排查的了，于是脑海里重新过一遍排查的过程。

1、本地连线上的数据库测试是正常的，所以数据库肯定是没问题的 2、项目程序也没问题：@JsonFormat(）并没有指定其他时区，字段类型也对的上；3、Linux时间也没问题，时区也设置了；

排查Docker

我突然想到项目是通过Docker 来构建的，难道是Docker内部的时区有问题，这是唯一还没有排查的地方了，于是查看Dockerfile配置文件！

很简单的配置呀，没理由出问题呀，为了保险起见；决定手动给他指定一个时区，最终的配置文件；添加配置：

# 安装tzdata(如果 设置时区不生效使用)
# RUN apk add --no-cache tzdata
# 设置时区
ENV TZ="Asia/Shanghai"

重新构建项目运行，再次测试，时间正常了。

欢迎加入我的知识星球，全面提升技术能力。

👉 加入方式，“长按”或“扫描”下方二维码噢：

星球的内容包括：项目实战、面试招聘、源码解析、学习路线。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）

线上系统时间慢八个小时的排查之路

相关推荐