完美解決方案-雪花演算法ID到前端之後精度丟失問題

字母哥部落格發表於2020-08-25

最近公司的一個專案組要把以前的單體應用進行為服務拆分,表的ID主鍵使用Mybatis plus預設 的雪花演算法來生成。

快下班的時候,小夥伴跑過來找我,:“快給我看看這問題,卡這卡了小半天了!”。連拉帶拽,連哄帶騙的把我拉到他的電腦前面。這位小夥伴在我看來技術不算是大牛,但經驗也很豐富了。他都卡了半天的問題,應該不是小問題,如果我一時半會搞不定,真的是耽誤我下班了,所以我很不情願的在他的位置坐了下來。

一、現象是這樣的

下面我把異常的現象給大家描述一下,小夥伴建了一張表,表的主鍵是id BigINT,用來儲存雪花演算法生成的ID,嗯,這個沒有問題!

CREATE TABLE user
(
	id BIGINT(20) NOT NULL COMMENT '主鍵ID',
        #其他欄位省略
);

使用Long 型別對應資料庫ID資料。嗯,也沒有問題,雪花演算法生成的就是一串數字,Long型別屬於標準答案!

@Data
public class User {
    private Long id;
//其他成員變數省略

在後端下斷點。看到資料響應以JSON響應給前端,正常

{
id:1297873308628307970,
//其他屬性省略
}

最後,這條資料返回給前端,前端接收到之後,修改這條資料,後端再次接收回來。奇怪的問題出現了:後端重新接收回來的id變成了:12978733086283000000,不再是1297873308628307970

二、分析問題

我的第一感覺是,開發小夥伴把資料給搞混了,張冠李戴了,把XXX的物件ID放到了YYY物件的ID上。所以,就按照程式碼從前端到後端、從後端到前端除錯跟蹤了一遍。

從程式碼的邏輯角度上沒有任何問題。這時,我有點煩躁了,真的是耽誤我下班了!但開工沒有回頭箭,既然坐下來了就得幫他解決,不然以後這隊伍怎麼帶?想到這我又靜下心來,開始思考。

1297873308628300000 ---> 1297873308628307970

這兩個數長得還挺像的,似乎是被四捨五入了。此時腦袋裡面冒出一個想法,是精度丟失了麼?哪裡能導致精度丟失?

  • 服務端都是Long型別的id,不可能丟失
  • 前端是什麼型別,JSON字串轉js物件,接收Long型別的是number

上網查了一下Number精度是16位(雪花ID是19位的),So:JS的Number資料型別導致的精度丟失。問題是找到了!
小夥伴投來敬佩的眼光,5分鐘就把這問題發現了。可是發現了有什麼用?得解決問題啊!

三、解決問題

開發小夥伴說:那我把所有的資料庫表設計,id欄位由Long型別改成String型別吧。我問他你有多少張表?他說100多張吧。

  • 100多張表還有100多個實體類需要改
  • 還有各種使用到實體類的Service層要改
  • Service等改完Controller層要改
  • 關鍵的是String和Long都是常用型別,他還不敢批量替換

小夥伴拿起電話打算訂餐,說今晚的加班是無法避免了。我想了想說:你最好別改,String做ID查詢效能會下降,我再想想!後端A到前端B出現精度丟失,要麼改前端,要麼改後端,要麼…… 。“哎哎,你等等先別訂餐,後端A到前端B你用的什麼做的序列化?” 小夥伴告訴我說使用的是Jackson,這就好辦了,Jackson我熟悉啊!


解決思路:後端的ID(Long) ==> Jackson(Long轉String) ==> 前端使用String型別的ID,前端使用js string精度就不會丟失了。 那前端再把String型別的19位數字傳回服務端的時候,可以用Long接收麼?當然可以,這是Spring反序列化引數接收預設支援的行為。


最終方案就是:前端用String型別的雪花ID保持精度,後端及資料庫繼續使用Long(BigINT)型別不影響資料庫查詢執行效率。

剩下的問題就是:在Spring Boot應用中,使用Jackson進行JSON序列化的時候怎麼將Long型別ID轉成String響應給前端。方案如下:

@Configuration
public class JacksonConfig {

  @Bean
  @Primary
  @ConditionalOnMissingBean(ObjectMapper.class)
  public ObjectMapper jacksonObjectMapper(Jackson2ObjectMapperBuilder builder)
  {
    ObjectMapper objectMapper = builder.createXmlMapper(false).build();

    // 全域性配置序列化返回 JSON 處理
    SimpleModule simpleModule = new SimpleModule();
    //JSON Long ==> String
    simpleModule.addSerializer(Long.class, ToStringSerializer.instance);
    objectMapper.registerModule(simpleModule);
    return objectMapper;
  }

}

小夥伴放下電話, 再次投來敬佩眼光。“走吧,一起下班!”我和小夥伴說,小夥伴一路上一直問我你是怎麼學習的?我冠冕堂皇的說了一些多想多學多問之類的話。
其實我心裡在想:我是一個懶人,但我不能說。能躺著絕不坐著,能自動絕不手動,能叫車絕不自己開車。第一次就把事情做對,才是省時省力做好的方法!這麼多年的“懶”,決定了我需要去思考更多的“捷徑”,思考“捷徑”的過程是我不斷進階的訣竅!
勤奮的人是社會的生產力,而懶人是社會的創造力!

歡迎關注我的部落格,裡面有很多精品合集

  • 本文轉載註明出處(必須帶連線,不能只轉文字):字母哥部落格

覺得對您有幫助的話,幫我點贊、分享!您的支援是我不竭的創作動力! 。另外,筆者最近一段時間輸出瞭如下的精品內容,期待您的關注。

相關文章