分佈式ID生成總結

1.數據庫自增id

新建一個公共庫，庫裏面新建一個序列表，主鍵id自增，每次請求增長數據都往這個表中插入數據，而後獲取到id，而後使用便可。

優勢：方便簡單

缺點：單庫生成自增id，高併發下，會有瓶頸

適用場景：

併發很低，幾百/s，不會出現性能瓶頸

2.UUID

優勢：本地生成，不基於任何第三方

缺點：

• 太長，做爲數據庫主鍵性能太差，不適合做爲主鍵
• 不具備有序性，會致使B+樹索引在寫的時候有過多的隨機寫操做（連續的id能夠產生部分順序寫）
• 寫的時候不能產生有順序的 append 操做，而須要進行 insert 操做，將會讀取整個 B+ 樹節點到內存，在插入這條記錄後會將整個節點寫回磁盤，這種操做在記錄佔用空間比較大的狀況下，性能降低明顯

適用場景：

隨機生成文件名、編號，生成token等。

3.系統時間+拼接業務字段值

例如：當前時間戳 + 用戶id + 業務含義編碼，併發高的時候，會有重複，此時就不行了，不建議使用。

4.Redis

Redis是單線程的，因此也能夠用生成全局惟一的ID。能夠用Redis的原子操做 INCR和INCRBY來實現。

優勢：

• 不依賴於數據庫，靈活方便，且性能優於數據庫。
• 數字ID自然排序，對分頁或者須要排序的結果頗有幫助。

缺點：

• 因爲redis是內存的KV數據庫，即便有AOF和RDB，可是依然會存在數據丟失，有可能會形成ID重複。
• 依賴於redis，redis要是不穩定，會影響ID生成。

5.snowflake算法

twitter開源的分佈式id生成算法，把一個64位的long型的id，1個bit是不用的，用其中的41 bit做爲毫秒數，用10 bit做爲工做機器id，12 bit做爲序列號，理論上最多支持1024臺機器每秒生成4096000個序列號。

• 1 bit：不用
  由於二進制裏第一個bit爲若是是1，那麼都是負數，可是咱們生成的id都是正數，因此第一個bit統一都是0
• 41 bit：表示的是時間戳，單位是ms
  41 bit能夠表示的數字多達2^41 - 1，也就是能夠標識2 ^ 41 - 1個毫秒值，換算成年就是表示69年的時間
• 10 bit：記錄工做機器id
  表明的是這個服務最多能夠部署在2^10臺機器上哪，也就是1024臺機器，可是10 bit裏5個bit表明機房id，5個bit表明機器id。意思就是最多表明2 ^ 5個機房（32個機房），每一個機房裏能夠表明2 ^ 5個機器（32臺機器）。
• 12 bit：記錄同一個毫秒內產生的不一樣id
  12 bit能夠表明的最大正整數是2 ^ 12 - 1 = 4096，也就是說能夠用這個12bit表明的數字來區分同一個毫秒內的4096個不一樣的id

缺點：

依賴於系統時鐘的一致性。若是某臺機器的系統時鐘回撥，有可能形成ID衝突，或者ID亂序、ID重複

優勢：

• 生成ID時不依賴於數據庫，徹底在內存生成，高性能高可用
• 容量大，每秒可生成幾百萬ID
• ID呈趨勢遞增，後續插入數據庫的索引樹的時候，性能較高