系統設計中跨時區問題的解決方案

作者：張張 2024-04-29 08:58:44

夏令時（Daylight Saving Time：DST），也叫夏時制，又稱“日光節約時制”和“夏令時間”，是一種為節約能源而人為規定地方時間的制度，在這一制度實行期間所采用的統一時間稱為“夏令時間”。一般在天亮早的夏季人為將時間調快一小時，可以使人早起早睡，減少照明量，以充分利用光照資源，從而節約照明用電。

一、背景

假如開發一套統一的系統產品，供遍布全球的所有分公司使用。

產品功能設計中，經常會遇到一場活動，分跨不同時區，系統需要顯示不同時區的時間，同時希望跨時區的用戶可以同一時間開始，同一時間結束。

對于類似跨時區處理問題，那我們該如何設計實現呢？

二、幾個重要概念

時區

劃分時區是為了便于人們進行跨地區的交流、協作和管理。

時區的劃分以地球表面按經線從東到西劃成一個個區域，每隔經度15°劃分一個時區，規定相鄰區域的時間相差1小時，如下圖所示：

圖片

格林尼治時間

英國皇家格林尼治天文臺，UTC/GMT 0 (零時區)。

中國時區

有東五區、東六區、東七區、東八區、東九區，新疆在東五、東六、而東北在東九區，但解放后我們國家統一采用北京時間（東八區）為準。

Coordinated Universal Time，世界統一時間，中國是UTC+8。

Greenwish Mean Time，以地球公轉和自轉來計算時間，而UTC以原子鐘來計算時間。

UNIX時間戳

1970年1月1日（UTC/GMT的午夜）開始所經過的秒數，因此，不同的時區的時間戳是相同的。

三、操作系統、數據庫時區設置

3.1 Linux 中設置時區

一臺Linux服務器有兩個時間源，一個是硬件時間，即服務器硬件CMOS維護的時間，還有一個是軟件時間，即操作系統維護的時間，前者通過hwclock命令來訪問，后者則主要通過date命令來訪問。

date是最常用的時間相關的命令，例如：

# 獲取當前時間
$ date
Fri Apr 26 15:22:16 CST 2024




# 以特定格式輸出當前時間，格式字符串前以"+"開頭，例如獲得當前時間的epoch
$ date +%s
1714117833




# 設置當前時間
$ sudo date -s "2024-04-25 00:00:00"
Thu Apr 25 00:00:00 CST 2024

如果是云服務器的話，中國區服務器默認都是UTC+8，海外機器則是UTC+0，關于這個大家再需要確認一下。

Linux 使用 tzselect 調整時區

該命令會向導式的選擇洲區、國家和城市，然后在/usr/share/zoneinfo下會生成時區的文件，將該文件覆蓋/etc/localtime即可完成時區設置。

#設置時區
tzselect

3.2 MySQL 中設置時區

先登錄到mysql 安裝所在的機器。

-- 看下當前的mysql時區設置
show variables like "%time_zone%";

下圖顯示 SYSTEM，表示用的默認時區。

圖片

我們可以修改成 +8 的北京所在時區，操作如下：

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

如上修改，MySQL如果重啟后，又會恢復之前的設置。

下面介紹一種設置，讓重啟永久生效的方案：修改設置，重啟永久生效。

修改配置文件 /etc/my.cnf

[mysqld]
default-time_zone = '+8:00'

重啟 MySQL 生效

systemctl stop mysqld.service
systemctl start mysqld.service

四、系統跨時區設計

現在我們回到正規，談談如何解決上面開篇提出的問題。

4.1 服務端中的時間處理

既然時區的處理不能在客戶端做，換言之就必須在服務端實現。

這樣就需要解決兩個問題：時間的保存和獲取。

客戶端傳來的時間為客戶端所在時區的當地時間，服務端接收到客戶端發送的時間后，需要基于客戶端相應時區轉換成UTC時間才能保存到數據庫。

圖片

所有后端暴露的接口中的時間對象，全部以 UTC 時間表示。

同時，所有后端在存儲、計算、傳輸時間時，也統一使用 UTC 時間。由于 DB 存儲時間時，時區信息會被丟掉，因此應保證丟掉的時區，是大家明確約定清楚的無歧義的，即 UTC。這樣一來，數據庫中的所有時間字段也都沒有歧義。

4.2 前端中的時間

時間在前端中的應用比較簡單，通常的方案是：后端直接返回 ISO 標準本地時間，避免 UTC 在前端再次格式化和處理時區，否則會把問題變得更加復雜（時區設置只發生在應用服務器中）。

如果有需要處理跨時區的業務場景需，可以讓用戶選擇時區，并在任何時候都將處理后的時區信息放到時間字符串中。

圖片

前端的時間格式化比較簡單，可以使用 Day.js 和 Moment.js 等時間庫來完成。

正是因為前面講到的時區問題，Moment.js 為了處理此問題，使用了一個巨大的 JSON 文件記錄了不同年份之間、不同國家、不同經緯度的時區信息，另外這些信息還會和語言信息綁定導致文件非常巨大。

4.3 其它注意事項

在編程中還有一些額外的坑可能需要注意：

使用環境變量配置時區信息，使用應用服務器來裁決時區（沒有特別業務說明的情況下），因此確保服務器配置的時區相同。
如果是跨國交易或者數據同步的時候，根據客戶端連接到的服務器來決定操作用戶所屬的時區。
依賴應用服務器的時區信息做時區裁決，不要依賴數據庫的時區設置，數據庫透明存放數據即可。
時區配置來源有操作系統、環境變量、數據庫時區、Java 啟動參數，建議統一使用 Java 啟動參數，避免配置出錯，數據庫不要做時區自動轉換，避免使用 TIMESTAMP 類型。
在高并發的場景中獲取系統時間可能有性能問題，原因是 JVM 需要訪問進入系統內核態執行指令，當高并發且不需要高精度時間時可以增加緩存，但需要權衡處理。
有時候在處理業務時，需要考慮自然月問題，需要特別注意。
關于時間同步問題中，還有一個墻上時鐘和單調時鐘的問題。墻上時鐘是指根據日歷獲取時間，會受到時間校對回撥的問題，而單調時鐘是指系統啟動后的秒數，它不會回撥。在使用 NTP 服務時，可以配置為 NTPD 模式，通過調慢時間頻率避免回撥。