Twitter-Snowflake算法產生的背景相當簡單，爲了滿足Twitter每秒上萬條消息的請求，每條消息都必須分配一條唯一的id，這些id還需要一些大致的順序（方便客戶端排序），並且在分佈式系統中不同機器產生的id必須不同。
Snowflake算法核心
把時間戳，工作機器id，序列號組合在一起。
除了最高位bit標記爲不可用以外，其餘三組bit佔位均可浮動，看具體的業務需求而定。默認情況下41bit的時間戳可以支持該算法使用到2082年，10bit的工作機器id可以支持1023臺機器，序列號支持1毫秒產生4095個自增序列id。下文會具體分析。
Snowflake – 時間戳
這裏時間戳的細度是毫秒級，具體代碼如下，建議使用64位linux系統機器，因爲有vdso，gettimeofday()在用戶態就可以完成操作，減少了進入內核態的損耗。
|
1
2
3
4
5
6
|
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機制也可以達到效果。
工作進程與工作id分配器只是在工作進程啓動的時候交互一次，然後工作進程可以自行將分配的id數據落文件，下一次啓動直接讀取文件裏的id使用。
PS：這個工作機器id的bit段也可以進一步拆分，比如用前5個bit標記進程id，後5個bit標記線程id之類:D
Snowflake – 序列號
序列號就是一系列的自增id（多線程建議使用atomic），爲了處理在同一毫秒內需要給多條消息分配id，若同一毫秒把序列號用完了，則“等待至下一毫秒”。
|
1
2
3
4
5
6
7
8
|
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可以在代碼實現上有效減少鎖的密度。
轉自
http://www.lanindex.com/twitter-snowflake，64位自增id算法詳解/
參考代碼
https://github.com/twitter/snowflake