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服務實現高可用
策略對比
