Twitter-Snowflake，64位自增ID算法详解
Twitter-Snowflake，64位自增ID算法詳解
ｆｒｏｍ： http://www.lanindex.com/twitter-snowflake%EF%BC%8C64%E4%BD%8D%E8%87%AA%E5%A2%9Eid%E7%AE%97%E6%B3%95%E8%AF%A6%E8%A7%A3/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); ????returncur; } |
?
總體來說，是一個很高效很方便的GUID產生算法，一個int64_t字段就可以勝任，不像現在主流128bit的GUID算法，即使無法保證嚴格的id序列性，但是對于特定的業務，比如用做游戲服務器端的GUID產生會很方便。另外，在多線程的環境下，序列號使用atomic可以在代碼實現上有效減少鎖的密度。
參考資料：https://github.com/twitter/snowflake
總結
以上是生活随笔為你收集整理的Twitter-Snowflake，64位自增ID算法详解的全部內容，希望文章能夠幫你解決所遇到的問題。
