标签:段值 updateTime 库存 Timestamp json 01 中台
背景
所在是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
标签:段值,updateTime,库存,Timestamp,json,01,中台 来源: https://www.cnblogs.com/cdfive2018/p/15984572.html
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。