分布式系统ID生成方案

自增ID

不错，能够限度抑制ID的大小。但须要有一个中心化的节点做为解决原子性问题。能够选用Redis，MySQL，Zookeeper。成本有点高。

 

UUID

分布式，并且惟一！缺点是生产的ID太长。

 

Twitter的SnowFlake算法

该算法能够生产分布式的自增ID。切生产的ID只有8字节，64位。其数据结构以下：

• 1位，不用。二进制中最高位为1的都是负数，可是咱们生成的id通常都使用整数，因此这个最高位固定是0

• 41位，用来记录时间戳（毫秒）。

  • 41位能够表示241−1个数字，
  • 若是只用来表示正整数（计算机中正数包含0），能够表示的数值范围是：0 至 241−1，减1是由于可表示的数值范围是从0开始算的，而不是1。
  • 也就是说41位能够表示241−1个毫秒的值，转化成单位年则是(241−1)/(1000∗60∗60∗24∗365)=69年

• 10位，用来记录工做机器id。

  • 能够部署在210=1024个节点，包括5位datacenterId和5位workerId
  • 5位（bit）能够表示的最大正整数是25−1=31，便可以用0、一、二、三、....31这32个数字，来表示不一样的datecenterId或workerId

• 12位，序列号，用来记录同毫秒内产生的不一样id。

  • 12位（bit）能够表示的最大正整数是212−1=4095，便可以用0、一、二、三、....4094这4095个数字，来表示同一机器同一时间截（毫秒)内产生的4095个ID序号

因为在Java中64bit的整数是long类型，因此在Java中SnowFlake算法生成的id就是long来存储的。

该算法生产的Id是在每台机器上都是按时间戳自增的。

能够根据实际需求变更该算法：好比能够工做机器Id长度。扩大序列号和时间戳。