查看原文
其他

系统设计中 跨时区问题 解决方案

张张 架构精进之路
2024-08-31
hello,大家好,我是张张,「架构精进之路」公号作者。

一、背景

假如开发一套统一的系统产品,供遍布全球的所有分公司使用。
产品功能设计中,经常会遇到一场活动,分跨不同时区,系统需要显示不同时区的时间,同时希望跨时区的用户可以同一时间开始,同一时间结束。
对于类似跨时区处理问题,那我们该如何设计实现呢?

二、几个重要概念

  • 时区
    划分时区是为了便于人们进行跨地区的交流、协作和管理。
    时区的划分以地球表面按经线从东到西划成一个个区域,每隔经度15°划分一个时区,规定相邻区域的时间相差1小时,如下图所示:

  • 格林尼治时间
    英国皇家格林尼治天文台,UTC/GMT 0 (零时区)。
  • 中国时区
    有东五区、东六区、东七区、东八区、东九区,新疆在东五、东六、而东北在东九区,但解放后我们国家统一采用北京时间(东八区)为准。
  • UTC
    Coordinated Universal Time,世界统一时间,中国是UTC+8。
  • GMT
    Greenwish Mean Time,以地球公转和自转来计算时间,而UTC以原子钟来计算时间。
  • UNIX时间戳
    1970年1月1日(UTC/GMT的午夜)开始所经过的秒数,因此,不同的时区的时间戳是相同的。

三、操作系统、数据库时区设置

3.1 Linux 中设置时区

一台Linux服务器有两个时间源,一个是硬件时间,即服务器硬件CMOS维护的时间,还有一个是软件时间,即操作系统维护的时间,前者通过hwclock命令来访问,后者则主要通过date命令来访问。

date是最常用的时间相关的命令,例如:
# 获取当前时间$ dateFri Apr 26 15:22:16 CST 2024

# 以特定格式输出当前时间,格式字符串前以"+"开头,例如获得当前时间的epoch$ date +%s1714117833

# 设置当前时间$ 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.servicesystemctl 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 模式,通过调慢时间频率避免回拨。

五、补充知识:夏令时、冬令时


夏令时(Daylight Saving Time:DST),也叫夏时制,又称“日光节约时制”和“夏令时间”,是一种为节约能源而人为规定地方时间的制度,在这一制度实行期间所采用的统一时间称为“夏令时间”。一般在天亮早的夏季人为将时间调快一小时,可以使人早起早睡,减少照明量,以充分利用光照资源,从而节约照明用电。
夏令时调整通常适用于:夏季日照时间相对较长,日出和日落时间发生较大变化的地方。关于夏令时的问题,人们褒贬不一。

有夏令时就会有冬令时,冬令时 通常是指当地使用的标准时间。在使用夏令时 - 日光节约时制(Daylight Saving Time) 的地区,夏天时钟拨快一小时,冬天再拨回标准时间。

那为什么我国取消夏令时呢?
调整的效果不大,其实不使用夏令时也能实现节约能源、减少照明成本的目的,只不过把调整人们生活节奏的权利给到了具体场景。在学校,会使用夏季和冬季课表,在工作环境中,某些公司也会针对下冬夏调整上班时间。

六、阅读更多及参考文献

本文参考资料:

  • https://en.wikipedia.org/wiki/Time_zone
  • https://zh.wikipedia.org/wiki/ISO_8601
  • https://www.rfc-editor.org/rfc/rfc3339
  • https://datatracker.ietf.org/doc/html/rfc5545
  • https://en.wikipedia.org/wiki/System_time
  • https://www.iplocate.com/
  • https://en.wikipedia.org/wiki/Timestamp

·END·

相关阅读:



专注架构技术研究,一起跨越职业瓶颈!

关注公众号,免费领学习资料



如果您觉得还不错,欢迎关注和转发~     

修改于
继续滑动看下一个
架构精进之路
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存