​    各种分布式全局唯一ID生成算法汇总大全(共12种)；设计分布式微服务系统，面试看这篇就够了。

   在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。在系统中，数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；此时一个能够生成全局唯一ID的系统是非常必要的。概括下来，那业务系统对ID号的要求有哪些呢？

1.     全局唯一性：不能出现重复的ID号，保证生成的 ID 全局唯一，这是最基本的要求。

2.     趋势递增：有利于保证DB插入、查询等操作的性能。

3.     单调递增：保证下一个ID一定大于上一个ID，例如版本号、排序等特殊需求。

4.     信息安全：如果ID是连续的，容易被猜测出url,ID号码的数量，对业务产生影响。所以在一些应用场景下，会需要ID无规则、不规则。

上述需求对应不同的场景，3和4需求还是互斥的，无法使其在同一个方案满足。

同时除了对ID号码自身的要求，业务还对ID号生成系统的可用性要求极高，想象一下，如果ID生成系统瘫痪，整个电商系统都无法完成业务，这就会带来一场灾难。

由此总结出一个ID生成系统应该做到如下几点：

     1.     平均延迟和TP999延迟都要尽可能低；

     2.     可用性5个9；

     3.     高QPS。

划重点了：如果前9种，你都看过了，就直接跳到第10种看吧。

分段模式与雪花到底有什么区别？

一个是依赖DB,一个是依赖时间的.

能不能找到一种，既不依赖DB，也不依赖时间的算法呢？答案是，肯定有的，找吧（本文就能找到）！

DB表自增ID真的不能用在分布式场景吗？  不要让前人把你的思维带偏了！

以下，将为大家讲解各种分布式全局唯一ID生成算法(共12种)。

  基于数据库自增ID（单个DB）

  基于数据库自增ID（主从DB结构）

UUID  全球唯一，但生成的是字符串。

Redis

号段模式

twitter snowflake   Twitter时钟回拨时直接抛异常。时钟回拨时会不可用。

美团leaf: 该篇文章详细的介绍了snowflake和db号段方案，近期也进行了Leaf开源。

还可以完善的地方：

没有：连续单调递增ID生成方案;没有批量获取ID号的方法。

snowflake弱化毫秒的时钟回拨，默认能容错5毫秒，避免润秒问题要在外部调用100次。弱依赖Zookeeper分配workerid.  返回结果用Result结构包装，会影响一点性能。时钟回拨时会不可用。

workerid有重复时，会有重号风险。workerid分配方案提供ZooKeeper，但想改其它分配方案需要改源码。

db号段模式属于依赖DB的号段模式，一次取一个号段的ID，减少对ID的访问。

8. 百度uid-generator: 这是基于snowflake方案实现的开源组件. 支持容器重启，workerid用后即弃，机器id占22位，最多可支持约419w次机器启动。

sequence (13 bits)每秒下的并发序列，13 bits可支持每秒8192个并发。

缺点：机器号占太多位，每个时间点能用的号码太少。

9. tinyid ：属于依赖DB的号段模式，一次取一个号段的ID，减少对ID的访问。

全局唯一的long型id

趋势递增的id，即不保证下一个id一定比上一个大

非连续性（不支持：连续单调递增ID）

优点：

支持批量获取id

支持多个db的配置，无单点

适用场景：只关心id是数字，趋势递增的系统，可以容忍id不连续，有浪费的场景

缺点：

不适用场景：类似订单id的业务(因为生成的id大部分是连续的，容易被扫库、或者测算出订单量)

作为分布式DB表主键，不是特别合适。不支持，连续单调递增ID，依赖DB。

以上几种算法还存在的问题。

依赖DB分段批量获取的算法，是可以产生全局唯一，且批内连续单调递增的ID。但多个请求分别调用生成一批,多个批都插入数据到库,还是不会连续的。强依赖DB。

雪花生成的是不连续，全局唯一,但只能是趋势递增的ID,部分区间连续，整体不连续。过于依赖时间。

因此又延伸出以下三种算法。

10. 梨花算法：改进的雪花算法，弱依赖时间，对毫秒不敏感，可以允许2分钟即120秒的时钟回拨（实际上可以根据业务场景设置更长或更短的容错时间），可以轻松避免润秒问题。workerid默认从配置文件获取，代码架构可方便扩展workerid分配算法，能处理workerid冲突问题。可提前消费1秒。。。

返回结果用原生long返回，异常使用小于0（