id生成器生成的id结构说明

id生成器生成的id的结构说明

目前id生成器支持生成以下几种id：

1. type == 0x4FF（1279）
   这种生成的id为后缀型id，也就是说这种id只生成最后的几位，前面的信息需要用户自己去补齐。
   模式：空位 + days * pow(10,5) + 顺序数 * 10 + mid
   特性：一般这种id使用在合同等生成上，前面是用户可以根据自己的业务特性来决定的数，一眼就能明了的，后面相当于一个随机数的情况。这种id会保存顺序数的状态，就算是id生成器重启也不会丢。 注意点：days为天数。最多为5位，所以整个id最长为10位。因为int64最大的数为19位，我们是有18位可以用，所以业务的数字最多只能用8位来表示。

2. type== 0/1/2
   这种生成分库分表的id。这个id为全id，开发者除了需要指定数据库，别的不需要再行去改动它。唯一性是有id生成器来保证的。
   模式：时间戳 * pow(10,8) + mid * pow(10,6) + 顺序数* pow(10,2),生成的id形如为：6864756600000000
   特性：这种id主要用来作为分库分表使用。顺序数将会是一个0-9999的循环数。2s内，id生成器保证递增，1s内，id生成器不保证递增。因为有一种情况无法避免：循环数计数到9999，然后下一跳是回0，这种情况会在1s发生，所以不保证在1s内递增。这种id的最后2位永远是“00”，这两位是数据库标识位，需要开发者根据自己的业务分库规则给每个id指明数据库的id。使用这个方法的好处是，扩展数据的时候不需要迁移数据。而分表即可根据顺序数来切分。

3. type == 98
   这种id主要是类型内递增的id。这种id千万不能用来分库分表。
   模式：时间戳 * pow(10,8) + mid * pow(10,6) + type * pow(10,4)+ 顺序数 ,生成的id形如为：6864758400980001
   特性：这种id严格保证生成的id是递增的。在跨秒的时候，顺序数都会被清零计算，比如1s的时候顺序被累加到20，2s的时候，就又从0开始就算了，所以这种id的分布是0-100的特别多，分库分表的话很容易引起数据表的不均匀。

4. type == 99
   这种id是上面type=98和type=0，1，2的结合版本。 模式：时间戳 * pow(10,8) + mid * pow(10,6) + type * pow(10,4)+ 顺序数 ,生成的id形如为：6864758400980001
   特性：这种id兼有了上面2，3的情况。顺序数从0-9999自增，不保证1s内生成的两个id肯定递增。但保证2s内生成的id是递增的。id上又兼有type类型。适合根据type需要做一些运算的情况。

5. 剩下的
   剩下的type< 255的id生成的id就类似于snowflow一样的。一个int64的数，根据二进制移位组成。这种数可以用来随便使用，没有很多的实际意义。
   模式：时间戳 << 28 | mid << 24 | type << 14 | next

注意

有一些开发需要根据时间戳来计算出id的时间表示，比如类似于yyyy-mm-dd的表示方式。id生成器的时间戳都不是linux系统的时间戳，1970-1-1 00:00:00，而是根据id生成器自己的时间基准（2015-01-01 00:00:00）生成的时间戳。