以JAVA為例
Twitter分布式自增ID算法snowflake，生成的是Long類型的id，一個Long類型占8個字節，每個字節占8比特，也就是說一個Long類型占64個比特（0和1）。
那么一個Long類型的64個比特，
twitter是這樣分配的：正數位（占1比特）+時間戳（占41比特）+機械id（占5比特）+數據中心（占5比特）+自增值（占12比特），總共64比特組成的一個Long類型。
時間戳（占41個比特）：毫秒數，大約可以使使用69年
機械id（占5個比特）：即2的5次方等於32個機器
數據中心id（占5個比特）：即2的5次方等於32個數據中心
自增值（占12比特）：2的12次方等於4096。也就是說每毫秒最多可以生成4096個id，如果cpu生產id的速度大於每毫秒4096個，那么需要使線程進行等待到下一毫秒，重新計數獲取自增值。
snowflake算法的好處：
# 生成的id是一個數字的Long類型
# 無需鏈接數據庫或者redis，超高性能。
# id根據時間成相對遞增
# id不連續，不易被猜測
snowflake算法的弊端：
# 每毫秒只能生成4096個id。隨着cpu不斷的進步，每毫秒4096個id將不能滿足。可以不用擔心，即便cpu性能超過了這個值，那么只需等待到下一個毫秒
# 只能使用69年
#每毫秒重新計數，空閑時間會浪費很多id空間。
#系統時間不可回退，回退將會導致id重復。另：系統時間可以前進，不受影響。
以上就是對snowflake的一些總結。
snowflake算法改進1：
針對空閑時間會浪費很多id空間，改進：咱們可以把時間戳的單位改為秒。使用31個比特的時間戳（秒），節約了10個比特，2的31次方等於2,147,483,648秒，約為69年。然后我們把節約出來的10個字節交給自增值，此時自增值（12+10=22比特），即2的22次方等於4,194,304。
改進前的snowflake算法結構為：正數位（占1比特）+時間戳（占41比特）+機械id（占5比特）+數據中心（占5比特）+自增值（占12比特）
改進后的snowflake算法結構為：正數位（占1比特）+時間戳（占31比特）+機械id（占5比特）+數據中心（占5比特）+自增值（占22比特）
改進后的優點：
# 避免空閑時間會浪費很多id空間，支持每秒生成419萬個id。
改進后的snowflake算法同樣是使用69年，時間戳以秒為單位，每秒支持約419萬個id生成。此時避免使用毫秒時間戳的浪費id空間的弊端。當然還可以繼續改進，比如：使用分鍾為單位的時間戳（要注意的是：使用分鍾為單位的時間戳，如果服務器宕機，那么你需要等待1分鍾后才能啟動服務器，否則將會導致自增值歸零重新計數，當前分鍾內生成的id和宕機時生成的id會重復）。