SimpleDateFormat 的一个小小的时间格式问题，竟然导致生产bug

wptr33 2025-10-14 06:14 20 浏览

业务背景

在存储大量数据，获取列表的业务场景下，我们采用了Mongodb的存储方式，其中标注时间业务的字段，均采用了String数据类型定义。

简述业务场景，A系统通过Http接口提交业务数据到系统B，请求参数存在唯一流水号标识；B系统存储业务数据到Mongodb中，异步去处理、组装数据提交到C系统（银行系统），系统C处理完数据以后，将会通过异步回调的形式通知系统B；系统B通过对应关系找到A系统的唯一流水号，进一步的异步回调给系统A。

发现问题

业务反馈，开发童鞋介入，发现系统A同一笔交易（业务单）编辑后，重新请求系统B，等到的回调竟然是业务单上一个版本的回调；且，系统A在接受回调的接口做了幂等操作，忽略了该次请求；导致的结果就是，业务编辑提交后许久，业务单一直处于处理中状态。

影响范围

发现部分业务单存在问题，大部分业务单是正常现象。排除了项目中统一时区的设定问题。

线下复现

复现的时间是上午，测试表示没有复现出来。很诡异！！！

排查问题

通过流水号观察日志，发现是B系统存储的在Mongodb中的时间字段，数据上存在问题，比如：创建时间是2022-05-01 14:24:10，然后系统存储的是2022-05-01 02:24:10。从而，系统B通过对创建时间倒排序后，获取业务单的最新一条记录时，获取的是业务单的第一笔请求流水。

服务器、mongodb节点

是否服务器时间问题，联系运维童鞋，查看了项目服务器各个节点当前时间，以及mongodb各个节点时间，结果都是正常的，问题又回归到了项目代码上。

排查代码

代码历史久远，最近一次迭代还是通过记录创建时间倒序查询。最后，发现问题。

demo复现

@Test
public void testTime() {
Date now = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
log.info("12小时制，时间:{}", sdf.format(now));
sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
log.info("24小时制，时间:{}", sdf.format(now));
}

[2022-05-01 14:35:34.106] [main] [INFO ] [com.xiu.boot.date.DateTest :26 ] 12小时制，时间:2022-05-01 02:35:34
[2022-05-01 14:35:34.107] [main] [INFO ] [com.xiu.boot.date.DateTest :28 ] 24小时制，时间:2022-05-01 14:35:34

紧急上线

开发修复bug，经过测试复现（修改了系统时间等操作），最后运维童鞋对系统进行平滑发布迭代修复上线。

事后复盘

1、业务场景发生概率下

业务单多次编辑，且在客户不撤销业务单，导致发现问题在上线迭代一段时间后。

2、历史代码，新需求场景

问题代码属于历史代码，新需求只是加了一个排序，导致对应开发童鞋坚持说不是代码的问题，影响了定位问题的方向。

3、问题定位方向错误

首先定位是项目时区设置，然后定位服务器时间不同步，最后定位代码。

4、系统A幂等处理结果优化

幂等处理的异常结果，不能忽略，应该直接报警处理。

date_format函数

上一篇：SimpleDateFormat线程不安全的5种解决方案
下一篇：python的format怎么用_python中format方法

SimpleDateFormat 的一个小小的时间格式问题，竟然导致生产bug

业务背景

发现问题

影响范围

线下复现

排查问题

紧急上线

事后复盘

相关推荐

程序员的开源月刊《HelloGitHub》第 71 期

如何将AI助手接入微信（打开ai手机助手）

SparkSQL——DataFrame的创建与使用

使用过 Redis 分布式锁么，它是什么回事?

Python第六讲:tuple_python tuple类型

VUE循环语句的使用(v-for)（vuefor循环的key）

Python rembg 库去除图片背景

HiveOs系统教程最细手把手教学（hiveos启动）

HIVE SQL基础语法（hive-sql）

Spring Boot 概述（spring boot干嘛的）