類snowflake演算法

**：

snowflake是twitter開源的分布式id生成演算法，其核心思想是：乙個long型的id，使用其中41bit作為毫秒數，10bit作為機器編號，12bit作為毫秒內序列號。這個演算法單機每秒內理論上最多可以生成1000*(2^12)，也就是400w的id，完全能滿足業務的需求。

借鑑snowflake的思想，結合各公司的業務邏輯和併發量，可以實現自己的分布式id生成演算法。

舉例，假設某公司id生成器服務的需求如下：

（1）單機高峰併發量小於1w，預計未來5年單機高峰併發量小於10w

（2）有2個機房，預計未來5年機房數量小於4個

（3）每個機房機器數小於100臺

（4）目前有5個業務線有id生成需求，預計未來業務線數量小於10個

（5）…

分析過程如下：

（1）高位取從2023年1月1日到現在的毫秒數（假設系統id生成器服務在這個時間之後上線），假設系統至少執行10年，那至少需要10年*365天*24小時*3600秒*1000毫秒=320*10^9，差不多預留39bit給毫秒數

（2）每秒的單機高峰併發量小於10w，即平均每毫秒的單機高峰併發量小於100，差不多預留7bit給每毫秒內序列號

（3）5年內機房數小於4個，預留2bit給機房標識

（4）每個機房小於100臺機器，預留7bit給每個機房內的伺服器標識

（5）業務線小於10個，預留4bit給業務線標識

這樣設計的

64bit

標識，可以保證：

（1）每個業務線、每個機房、每個機器生成的id都是不同的

（2）同乙個機器，每個毫秒內生成的id都是不同的

（3）同乙個機器，同乙個毫秒內，以序列號區區分保證生成的id是不同的

（4）將毫秒數放在最高位，保證生成的id是趨勢遞增的

缺點：

（1）由於「沒有乙個全域性時鐘」，每台伺服器分配的id是絕對遞增的，但從全域性看，生成的id只是趨勢遞增的（有些伺服器的時間早，有些伺服器的時間晚）

最後乙個容易忽略的問題：

生成的id，例如message-id/ order-id/ tiezi-id，在資料量大時往往需要分庫分表，這些id經常作為取模分庫分表的依據，為了分庫分表後資料均勻，id生成往往有「取模隨機性」的需求，所以我們通常把每秒內的序列號放在id的最末位，保證生成的id是隨機的。

又如果，我們在跨毫秒時，序列號總是歸0，

會使得序列號為0的id比較多，導致生成的id取模後不均勻

。解決方法是，序列號不是每次都歸0，而是歸乙個0到9的隨機數，這個地方。