背景

所在是ToC部门，面向C端用户，商品库存数据跟中台库存服务进行了对接，通过MQ消息、OSS文件对接增量库存变动以及全量库存。
某日收到业务反馈线上有个门店商品的库存数据没对，跟中台不一致。

问题排查

检查这边的库存服务、消息队列都没有异常。
搜索日志找到库存全量文件位置，找到商品库存当天凌晨值为81；
查看增量库存消息接收日志，找到今天只有一条库存增量变动为-36，相减为45，这边数据显示为81，中台为45，可见是-36没有扣减成功；
在库存服务日志里没有发现消息消费异常；
定位到代码，在变动库存之前，先在Redis查询了之前的库存对象(hash存储)，取出了updateTime跟消息里的updateTime字段进行了比对，
如果消息里的修改时间更早，则表示数据不是最新改动，跳过不更新。
而MQ消息里的updateTime值为0

本地测试

测试由0转Timestamp：
// pay attention to this
Timestamp timestamp0 = new Timestamp(0);
// 1970-01-01 08:00:00.0
System.out.println(timestamp0);

注意到通过Timestamp(long)构造函数创建Timestamp对象，打印出来的时间为java的默认起始时间。

因MQ消息里是json格式，在项目接入MQ的基础框架里，通过fastjson转换，本地测试如下：
先定义一个待转换的对象：

@Data
private static class Item implements Serializable {

    private Timestamp updateTime;
}

测试json转换：

// test json convert using fastjson
String json = "{\"updateTime\":0}";
Item item = JSONObject.parseObject(json, Item.class);
// {"updateTime":0}
System.out.println(JSONObject.toJSONString(item));
// 1970-01-01 08:00:00.0
System.out.println(item.updateTime);

测试结果显示，0值通过fastjson转换到对象的Timestamp类型字段，值为java的默认起始时间。

沟通解决

跟中台的产品和开发反馈，那边检查后确定是因为某些业务场景下没有设置该值；
因为中台是上游系统数据来源，经沟通由中台检查遗漏的场景，保证该值为库存最新修改时间，由下游系统使用。
临时处理方案为，业务在系统后台手动同步库存。

参考

为什么java的时间从1970年1月1日开始 https://baijiahao.baidu.com/s?id=1611184991110524995