需求

• 生成全域性唯一的ID
• 趨近有序(例如：1 3 4 6 9 18)

解決方案(涉及到資料以MySql為例)

• 方案一：使用原生資料庫的 auto_increment 來生成全域性唯一ID
  
  • 優點：
    
    • 原生資料庫簡單快捷
    • 保證可靠唯一性
    • 步長有序固定
  • 缺點：
    
    • 不能保證高可用性，資料庫常見的架構：一主多從(master+slave),本問題寫居多，master庫掛了就玩完了
    • 擴充套件性差，效能依賴master庫寫入的效能
  • 優化方案：
    
    • 新增master、避免單點寫入
    • 資料水平切分，保證每個庫生成的ID 不重複
    • 見下圖：
      
    • 1庫平行擴充套件為4個庫，分攤了寫入的壓力
    • Mysql 這邊需要自行設定auto_increment_offset 確定AUTO_INCREMENT列值的起點，也就是初始值。auto_increment_increment控制列中的值的增量值，也就是步長。
    • [email protected][kevin]> set session auto_increment_offset=1;
    • [email protected][kevin]> set session auto_increment_increment=4;
    • 不足之處：相對保持ID遞增，不過一般專案足矣
• 方案二：單點生成ID服務,預生成id
  
  • 詳解：資料庫裡記錄最後一次分配的最大id，初始為max_id=1,假如第一生成 6個ID，第一步：generate-server 先獲取資料庫的max-id=0,第二步：然後更新 max_id=（0+6），generate-server 拿到初始max-id和本次拉取id個數生成ID,max_id < 生成ID集合 < (max_id+N)
  • 示意圖：
    
  • 單點服務+shadow 服務保證高可用性
  • 批量生成ID大大降低了資料庫壓力，且能保證ID 相對遞增
  • 每秒生成10W級的ID

• 方案三：本地生成 ID策略，依賴演算法

  • 下面講解snowflake演算法，下面提供 PHP snowflake 的擴充套件
    
  • Twitter-Snowflake演算法產生的背景相當簡單，為了滿足Twitter每秒上萬條訊息的請求，每條訊息都必須分配一條唯一的id，這些id還需要一些大致的順序（方便客戶端排序），並且在分散式系統中不同機器產生的id必須不同。
  • Snowflake演算法核心,把時間戳，工作機器id，序列號組合在一起。
  • 
  • 除了最高位bit標記為不可用以外，其餘三組bit佔位均可浮動，看具體的業務需求而定。預設情況下41bit的時間戳可以支援該演算法使用到2082年，10bit的工作機器id可以支援1023臺機器，序列號支援1毫秒產生4095個自增序列id。下文會具體分析。

  • Snowflake – 時間戳
    這裡時間戳的細度是毫秒級，具體程式碼如下，建議使用64位linux系統機器，因為有vdso，gettimeofday()在使用者態就可以完成操作，減少了進入核心態的損耗。

    uint64_t generateStamp()
    {
        timeval tv;
        gettimeofday(&tv, 0);
        return (uint64_t)tv.tv_sec * 1000 + (uint64_t)tv.tv_usec / 1000;
    }

    預設情況下有41個bit可以供使用，那麼一共有T（1llu << 41）毫秒供你使用分配，年份 = T / (3600 * 24 * 365 * 1000) = 69.7年。如果你只給時間戳分配39個bit使用，那麼根據同樣的演算法最後年份 = 17.4年。

  • Snowflake – 工作機器id
    嚴格意義上來說這個bit段的使用可以是程序級，機器級的話你可以使用MAC地址來唯一標示工作機器，工作程序級可以使用IP+Path來區分工作程序。如果工作機器比較少，可以使用配置檔案來設定這個id是一個不錯的選擇，如果機器過多配置檔案的維護是一個災難性的事情。
    這裡的解決方案是需要一個工作id分配的程序，可以使用自己編寫一個簡單程序來記錄分配id，或者利用Mysql auto_increment機制也可以達到效果。

  • snowflake - 工作id
    工作程序與工作id分配器只是在工作程序啟動的時候互動一次，然後工作程序可以自行將分配的id資料落檔案，下一次啟動直接讀取檔案裡的id使用。

    PS：這個工作機器id的bit段也可以進一步拆分，比如用前5個bit標記程序id，後5個bit標記執行緒id之類:D

  • Snowflake – 序列號
    序列號就是一系列的自增id（多執行緒建議使用atomic），為了處理在同一毫秒內需要給多條訊息分配id，若同一毫秒把序列號用完了，則“等待至下一毫秒”。

    
    uint64_t waitNextMs(uint64_t lastStamp)
    {
        uint64_t cur = 0;
        do {
            cur = generateStamp();
        } while (cur <= lastStamp);
        return cur;
    }

    總體來說，是一個很高效很方便的GUID產生演算法，一個int64_t欄位就可以勝任，不像現在主流128bit的GUID演算法，即使無法保證嚴格的id序列性，但是對於特定的業務，比如用做遊戲伺服器端的GUID產生會很方便。另外，在多執行緒的環境下，序列號使用atomic可以在程式碼實現上有效減少鎖的密度。