JAVA平臺分散式自增長ID 的解決方案分析對比

全域性ID解決方案一： redis

Redis的incr自增函式來維護全域性ID，設計的關鍵地方：

1. key的長度；長度影響效率和儲存容量

2. key的命名規則：無規則，維護困難，不能見名知意，瞭解所屬業務板塊

3. 需要人工干預機制：為了效能，redis設計為無狀態，非持久化，遇到機器故障，重啟redis會丟失所有的當前ID值，需要提供人工init操作，讀取業務MAXID，同步ID。

優點：不受限js的number型別最大值。位數控制在16位以內。Restful API 開發不需要資料型別轉化，減少不必要的程式碼量，提高了維護性和開發效率。

缺點：key隨著業務的擴充套件，越來越難維護，為了效率，不能持久化，故障重啟需要人工干預，提供人工干預機制。

全域性ID解決方案二：JAVA

64位ID (42(毫秒)+5(機器ID)+5(業務編碼)+12(重複累加))

優點：效率高，支援高併發，ID幾乎無重複值。

缺點：受限js的number型別最大值。超過此值，精度丟失。

原因：js的number型別有個最大值（安全值）。即2的53次方，為9007199254740992。如果超過這個值，那麼js會出現不精確的問題。這個值為16位。超過16位的數值需要在後端轉化成字串型別，傳遞到前端使用，增加了程式碼開發量，降低了開發效率。最優方案就是設計一個不超過