背景
所在是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