PostgreSQL 同步到 ES 后时间类型少了 8 小时

简述

最近我致力于实现 PostgreSQL 到 Elasticsearch(ES)的实时同步功能。

在源端,我利用 PostgreSQL(PG)的 Write-Ahead Logging(WAL)日志来实现实时同步,将 WAL 转换为 ES 的相关写入操作。

源端 PG 数据库和 ES 均采用 UTC 时区,因此 Timestamp 类型的同步应该无需进行任何处理。

然而,在将数据写入 ES 后,我们却发现 Timestamp 类型的数值少了 8 个小时。

原因分析

首先,让我们梳理一下整个同步链路:

PG 的数据经过 SYNC 程序处理,然后同步到 ES。

经过初步分析,我们得出两个可能的原因:

  1. ES 中的时间存储正确,而 Kibana 使用的是浏览器的时区(Asia/Shanghai)。
  2. SYNC 程序在处理时间时出现了问题。

在 Kibana 设置中查看后,发现其设置为 UTC,即不会默认进行任何时区转换,因此我们推断问题出现在 SYNC 程序的时间处理中。

代码分析

在处理时间类型的代码中,存在以下逻辑,首先会使用parseDate方法将时间类型的字符串转换为DateTime

java 复制代码
public static DateTime parseDate(String datetimeStr) {
    // ... 省略部分代码 ...
    try {
        return new DateTime(datetimeStr);
    } catch (IllegalFieldValueException e) {
        String errMsg = "Parse date fail, Root cause is " + ExceptionUtils.getRootCauseMessage(e);
        log.error(errMsg);
        throw e;
    }
}

通过调试,我们发现在parseDate后,时间减少了 8 小时。

源码分析

TimeZone.getDefault()是 JDK 自带的方法:

获取 Java 虚拟机的默认时区。

如果缓存的默认时区可用,则返回其克隆。

否则,该方法采取以下步骤来确定默认时区。

使用默认时区的风险

当JVM中的user.timezone变量未设置值时,根据上述源码分析,将读取系统的默认时区。

风险就出在这里,如果系统安装时时区未正确设置,将导致程序获取的默认时区与预期不符,从而引发异常。

在 Java 程序中设置时区

  1. 在 Java 程序启动时,在 JVM 参数中添加-Duser.timezone=UTC
  2. 在程序首次启动时,使用TimeZone.setDefault()来设置时区。
相关推荐
大只鹅7 分钟前
WebSocket类明明注入了Bean,为什么报错为null
java·websocket
ChinaRainbowSea15 分钟前
9-2 MySQL 分析查询语句:EXPLAIN(详细说明)
java·数据库·后端·sql·mysql
时序数据说17 分钟前
Java类加载机制及关于时序数据库IoTDB排查
java·大数据·数据库·物联网·时序数据库·iotdb
wowocpp17 分钟前
rabbitmq 与 Erlang 的版本对照表 win10 安装方法
java·rabbitmq·erlang
风象南21 分钟前
SpringBoot基于Java Agent的无侵入式监控实现
java·spring boot·后端
崎岖Qiu27 分钟前
【Spring篇08】:理解自动装配,从spring.factories到.imports剖析
java·spring boot·后端·spring·面试·java-ee
belldeep34 分钟前
java:如何用 JDBC 连接 TDSQL 数据库
java·数据库·jdbc·tdsql
2301_1472583691 小时前
7月2日作业
java·linux·服务器
香饽饽~、1 小时前
【第十一篇】SpringBoot缓存技术
java·开发语言·spring boot·后端·缓存·intellij-idea
小莫分享2 小时前
移除 Java 列表中的所有空值
java