分布式 id生成全局唯一(分布式唯一id生成策略)

在应用程序中，通常需要一个全局唯一的ID作为数据库的主键。如何生成一个全局唯一的ID？

首先，您需要确定全局唯一ID是整数还是字符串。如果是字符串，那么现有的UUID完全满足要求，不需要额外的工作。缺点是string作为ID占用大量空间，索引效率低于integer。

如果使用整数作为ID，那么首先排除32位int类型，因为范围太小，必须使用64位long类型。

使用整数作为ID时，如何生成一个自增的、全局唯一的、不重复的ID？

方案一：利用数据库的自增ID，从1开始，基本可以持续增加。Oracle可以用SEQUENCE，MySQL可以用AUTO_INCREMENT的主键，虽然不能保证全局唯一，但是每个表都是唯一的。

也基本满足需求。

数据库自增ID的缺点是在插入数据之前无法获取ID。插入数据后，获得的ID是唯一的，但在提交交易之前它是无效的。一些双向引用的数据要重新插入更新，比较麻烦。

第二种方法是使用集中式ID生成器，它可以是Redis、ZooKeeper，或者通过使用数据库中的表来记录最后分配的ID。

这种方式最大的缺点是过于复杂，需要严重依赖第三方服务，代码配置繁琐。一般来说，方案越复杂，越不可靠，测试起来越痛苦。

第三种方式是类似Twitter的雪花算法，给每台机器分配一个唯一ID，然后通过时间戳ID自动增加全局唯一ID。这种方法的优点是ID生成算法完全没有状态机和网络调用，高效可靠。

缺点是如果唯一标识符重复，会造成ID冲突。

雪花算法采用41位毫秒时间戳，加上10位机器ID和12位序列号，理论上最多支持1024台机器每秒生成4096000个序列号，对于Twitter的规模来说足够了。

但对于大多数普通应用来说，不需要超过每秒400万个id，机器数量在1024以内。因此，我们可以改进它，使用一种更短的ID生成方法：

53bitID由32位秒级时间戳和16位自增5位机器标识组成，累计32台机器，每秒生成65000个序列号。核心代码是：

private static synchronized long nextId(long epochSecond){ if(epochSecond last epoch){//警告：时钟被转回：logger。warn('时钟回来了：从上一个纪元返回到下一个纪元')；epoch second=last epoch } if(last epoch！=epochSecond){ last epoch=epochSecond；reset()；}偏移；long next=offset MAX _ NEXTif(next==0){ logger。警告('纪元中一秒内达到最大id:“纪元秒”)；返回nextId(epochSecond 1)；}返回generateId(epochSecond，next，SHARD _ ID)；}时间戳减去一个固定值，

每秒65000个序列号不够用怎么办？没关系，可以继续递增时间戳，“借用”下一秒的65000个序列号。

同时也解决了时间回调的问题。

机器标识采用简单的主机名方案。只要主机名符合host-1，host-2就可以自动提取机器标识，无需配置。

最后，为什么要用最大53位整数而不是64位整数？这是因为考虑到大部分应用都是Web应用，如果要和JavaScript打交道，因为JavaScript支持的最大整数是53位，超过这个数，

JavaScript会失去精确性。所以使用53位整数可以直接被JavaScript读取，超过53位就必须转换成字符串才能保证JavaScript处理正确，这样会给API接口带来额外的复杂度。

这也是为什么新浪微博的API接口会同时返回id和idstr。