最近有一個(gè)新項(xiàng)目上線，在上線時(shí)，突然發(fā)現(xiàn)時(shí)間與正常時(shí)間對(duì)不上，少了八個(gè)小時(shí)；但我絲毫不慌，這不就是個(gè)時(shí)區(qū)的問題嗎，簡(jiǎn)單，但是這一次它給我深深的上了一課，一起來(lái)看整個(gè)排查過程吧。

開始排查

排查數(shù)據(jù)庫(kù)

一般的時(shí)區(qū)問題都是數(shù)據(jù)庫(kù)配置或數(shù)據(jù)鏈接參數(shù)的配置問題，于是我立馬就定位到了問題，應(yīng)該是數(shù)據(jù)庫(kù)的時(shí)區(qū)設(shè)置錯(cuò)了，于是我愉快的查看了數(shù)據(jù)庫(kù)時(shí)區(qū)

?

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

?

1、system_time_zone：全局參數(shù)，系統(tǒng)時(shí)區(qū)，在MySQL啟動(dòng)時(shí)會(huì)檢查當(dāng)前系統(tǒng)的時(shí)區(qū)并根據(jù)系統(tǒng)時(shí)區(qū)設(shè)置全局參數(shù)system_time_zone的值。值為CST，與系統(tǒng)時(shí)間的時(shí)區(qū)一致。

2、time_zone：全局參數(shù)，設(shè)置每個(gè)連接會(huì)話的時(shí)區(qū)，默認(rèn)為SYSTEM，使用全局參數(shù)system_time_zone的值。

CST時(shí)間

CST時(shí)間：中央標(biāo)準(zhǔn)時(shí)間。CST可以代表如下4個(gè)不同的時(shí)區(qū)：

Central Standard Time (USA) UT-6:00，美國(guó)

Central Standard Time (Australia) UT+9:30，澳大利亞

China Standard Time UT+8:00，中國(guó)

Cuba Standard Time UT-4:00，古巴

再次分析

很顯然，這里與UTC時(shí)間無(wú)關(guān)，它只是時(shí)間標(biāo)準(zhǔn)。目前Mysql中的system_time_zone是CST，而CST可以代表4個(gè)不同的時(shí)區(qū)，那么，Mysql把它當(dāng)做哪個(gè)時(shí)區(qū)進(jìn)行處理了呢？

簡(jiǎn)單推算一下，中國(guó)時(shí)間是UT+8:00，美國(guó)是 UT-6:00，當(dāng)傳入中國(guó)時(shí)間，直接轉(zhuǎn)換為美國(guó)時(shí)間（未考慮時(shí)區(qū)問題），時(shí)間便慢了14個(gè)小時(shí)。

既然知道了問題，那么解決方案也就有了。

解決方案

方案一：修改數(shù)據(jù)庫(kù)時(shí)區(qū)

既然是Mysql理解錯(cuò)了CST指定的時(shí)區(qū)，那么就將其設(shè)置為正確的。

連接Mysql數(shù)據(jù)庫(kù)，設(shè)置正確的時(shí)區(qū)：

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

再次執(zhí)行show命令查看：show variables like '%time\_zone%';。

這里我選擇方案2：修改數(shù)據(jù)庫(kù)連接參數(shù)

>?基于?Spring?Cloud?Alibaba?+?Gateway?+?Nacos?+?RocketMQ?+?Vue?&?Element?實(shí)現(xiàn)的后臺(tái)管理系統(tǒng)?+?用戶小程序，支持?RBAC?動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能
>
>?*?項(xiàng)目地址：
>?*?視頻教程：

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

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

到這里，我想著問題肯定已經(jīng)解決了；愉快的測(cè)了一手；結(jié)果還是差八個(gè)小時(shí)？但是本地項(xiàng)目的時(shí)間是正常的啊，我開始有了不祥的預(yù)感; 于是我本地連上線上的數(shù)據(jù)庫(kù)開始測(cè)試，發(fā)現(xiàn)時(shí)間是正常的。到這里，就基本排查出不是MySQL的問題。

排查 Linux

我開始懷疑是不是 linux 系統(tǒng)的時(shí)區(qū)有問題；

?

查看硬件的時(shí)間：hwclock --show

?

?

查看系統(tǒng)的時(shí)間：date -R

?

發(fā)現(xiàn)Linux的時(shí)間四年沒問題的，于是開始查服務(wù)器的時(shí)區(qū)配置 查看時(shí)區(qū) TZ配置：echo $TZ

發(fā)現(xiàn)為空，于是查看系統(tǒng)配置；查看系統(tǒng)配置命令：env

發(fā)現(xiàn)確實(shí)沒有 TZ 的配置，系統(tǒng)并未設(shè)置TZ變量，而是通過localtime指定時(shí)區(qū)；于是我修改 localtime的指定。

?

先刪除TZ環(huán)境變量：unset TZ

?

?

再執(zhí)行：ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 命令etc目錄下創(chuàng)建名稱是localtime的快捷鍵指定到上海時(shí)區(qū)文件上；

?

修改完成后，果斷重啟項(xiàng)目測(cè)試，結(jié)果令人失望，時(shí)間依舊沒有變化，于是嘗試直接加上 TZ配置

?

命令：export TZ=Asia/Shanghai

?

再次查看：

可以看到 TZ配置已經(jīng)設(shè)置成功，到這里我似乎看到了希望；于是再次測(cè)試，然后我人傻了，時(shí)間依舊少八個(gè)小時(shí)；到這里，我實(shí)在是不知道還有什么是沒排查的了，于是腦海里重新過一遍排查的過程。

1、本地連線上的數(shù)據(jù)庫(kù)測(cè)試是正常的，所以數(shù)據(jù)庫(kù)肯定是沒問題的 2、項(xiàng)目程序也沒問題：@JsonFormat(）并沒有指定其他時(shí)區(qū)，字段類型也對(duì)的上；3、Linux時(shí)間也沒問題，時(shí)區(qū)也設(shè)置了；

排查Docker

我突然想到項(xiàng)目是通過Docker 來(lái)構(gòu)建的，難道是Docker內(nèi)部的時(shí)區(qū)有問題，這是唯一還沒有排查的地方了，于是查看Dockerfile配置文件！

很簡(jiǎn)單的配置呀，沒理由出問題呀，為了保險(xiǎn)起見；決定手動(dòng)給他指定一個(gè)時(shí)區(qū)，最終的配置文件；添加配置：

#?安裝tzdata(如果?設(shè)置時(shí)區(qū)不生效使用)
#?RUN?apk?add?--no-cache?tzdata
#?設(shè)置時(shí)區(qū)
ENV?TZ="Asia/Shanghai"

重新構(gòu)建項(xiàng)目運(yùn)行，再次測(cè)試，時(shí)間正常了。

編輯：黃飛