背景

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