snowflake做主键 自增_Twitter分布式自增ID算法snowflake原理解析（订单id生成）

snowflake

通常情况下，用时间来表示是最简单的，如果同一时间(毫秒)有很多请求进来怎么办？

时间戳后面拼接上一个数字，这个数字可以通过锁控制每次递增，每毫秒清零，重新开始递增。

即便这样，只是解决了单机的问题，如果是分布式环境，不同的机器，还是可能产生一样的id的，这怎么解决？

在上述时间戳和数字的基础上在拼接上机器的id，这样就不会重复了。

不同的数据中心，机器id是可能重复的，怎么搞？

再拼接上数据中心的id就行了。

不同的星球上。。。

思想朴实无华，但是大道至简。

最终产生的id是这个样子的，时间戳，工作机器id，序列号可以根据实际需要调整长度(通常情况下不需要调整，完全够用)，总体64bit就行：

以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，超高性能。

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会重复)。