分布式、高并發下的ID生成政策

1、分布式、高并發下的ID生成要求

• 全局唯一
• 趨勢遞增
• 效率高（生成、使用、索引）
• 控制并發

政策一：UUID/GUID（通用唯一識别碼）

UUID按照開放軟體基金會（OSF）指定的标準計算。

用到了以太網遞增（MAC）、納秒級時間、晶片ID碼和許多可能的數組。

由一下幾部分的組合：

• 目前日期和時間
• 時鐘序列
• 全局唯一的IEEE機器識别号

示例UUID，長度為36的字元串：3skci324-sdf4-842k-4k23d3ea32ff

優點：

• 使用簡單
• 不依賴其他元件
• 不影響資料庫擴充

缺點

• 資料庫索引效率低
• 太過于無意義，使用者不友好
• 長度36的字元串，空間占用大
• 應用叢集環境，機器多的時候，重複幾率大

政策二：資料庫自增長

優點

• 無需編碼
• 性能不錯
• 索引友好

缺點

• 大表不能做水準分表，否則插入删除易出現問題
• 依賴前期規劃，拓展性不好
• 依賴mysql内部維護“自增鎖”，高并發下插入資料影響性能
• 在業務進行表關聯插入時，要"先父後子"

政策三：推特的雪花算法

snowflak算法是Twitter開源的分布式ID生成算法，結果是一個long長整型的ID。

由1bit -未使用的0+41bit-時間戳+10bit-工作機器ID+12bit-序列号四部分組成， 64bit=8位元組=long的占用位元組（轉化為字元串後長度最多19）。

優點

• 性能較優，速度快
• 無需第三方依賴，實作簡單
• 可以根據實際情況調整和拓展算法，友善靈活

缺點

• 依賴機器時間，如果發生回撥會可能導緻生成重複ID，業界的使用根據snowflak拓展

政策四：基于Redis自增

利用增長技術API，業務系統在自增長的基礎上，配合其他資訊組裝成為一個唯一ID。

Redis的incr（key） API用于将key的值進行遞增，并傳回增長數組。如果key不存在，則建立并指派為0。

利用到Redis的特性：單線程原子操作、自增計數API、資料有效期EX。

示例：業務編碼+地區+自增數值。（9 020 0000000001）

優點

• 拓展性強，可以友善的結合業務進行處理
• 利用Redis操作原子性的特性，保證在并發的時候不會重複

缺點

• 引入Redis就意味着引入其他第三方的依賴
• 增加一次網絡開銷
• 需要對Redis服務實作高可用

政策對比