分布式系统全局唯一ID的几种实现方式

现如今可谓是微服务、分布式、IoT（物联网）横行的时代，作为一名开发者始终还是要保持一定的危机意识，特别是在日常的项目开发中，若是有机会接触到一些关于微服务、分布式下的应用场景，应当硬着头皮、排除万难，主动应承下来上去大干一场；这期间不管结果如何，积累下来的经验将会让自己受益匪浅；而本文要介绍的“分布式全局唯一ID”便是一种典型的分布式应用场景！！！
话不多说，咱们直接进入正题~~~

说起这个全局唯一ID，你可能会第一时间想到“数据库的自增主键”、“UUID”、“雪花算法”等等，更有甚者，还能说出一些大厂开源的组件，比如滴滴的IDWorker、美团的Leaf等等，没错，这些确实是可以实现全局唯一ID的方案，你能想到这些点，那涉猎其实还是挺广的。

而对于“全局唯一ID/编号/编码”的应用场景，在现实生活中还是比较多的，比如电商平台中“订单系统”的订单编号，“进销存系统”中的商品编号、订单编号，“支付”过程中订单流水号等等；接下来debug将会总结性的介绍下目前市面上比较流行的“全局唯一ID”的几种实现方式，并针对分布式场景下的几种实现方式进行代码实战。

话不多说，直接进入正题，先贴张思维导图吧，总结性地概括下目前网上比较流行的几种方式

结合上图几种方式，再概括性的介绍下吧：

1、数据库的自增主键

简介：这一点相信写过代码的小伙伴都晓得，主要利用主键ID的auo_increment特性，每进来一条数据时数据库自动为其生成当前最大的ID并作为该条记录的主键；

优点：简单、便捷；

缺点：只能限于单机，严重依赖于DB，仅可限于DB相关的业务，可用性还是有点差；

TIPS: 生成的id是连续的吗？https://www.jianshu.com/p/369559f399d0

2、批量预生成ID

简介：DB只存储当前最大的ID值，每次需要ID时，则按照顺序批量生成N个有序的ID列表，并将最大的ID值 + N。

优点：相对于第一种方式性能还是提高了不少；

缺点：仍然得依赖于DB，可用性还是有点差；而且批量生成的ID可能断层（比如服务挂了然后重启就可能跳过部分ID，如果服务有多个，将难以保证其有序性）

TIPS：已废弃 20200708 go服务billno解耦方案

3、 UUID的方式

简介：通用唯一识别码，这个估计众所周知啦，不作过多的介绍了！
优点：简单，直接 UUID.randomUUID().toString()即可搞定；

缺点：比较长、占用空间大；无序且不利于索引，在实际项目中不建议使用；特别是在插入数据库时如果用UUID生成的ID作为主键的话，很可能会引起B+树的不断重平衡；

4、基于时间戳

简介：比如按照规则：yyyyMMdd+ N位随机数或者 yyyyMMddHHmmss + N位随机数。

优点：可行，而且生成的ID编号前半段有序，有一定的业务意义；

缺点：当并发产生的数据量比较大时，那N位随机数会出现重复的可能（虽然可以通过各种方式去重，比如Redis的Set，但代价还是相当高的，因为得不断的 while判断是否重复…）

**TIPS：**linux下生成随机数 https://blog.51cto.com/13236892/2426623

5、SnowFlake算法

简介：Twitter开源的一种分布式ID生成算法，结果是一个Long型的64位的ID；其核心思想是将64位划分为各个段，其中0号位不用，连续41位表示时间戳，连续10位表示工作机器ID，最后12位则表示毫秒级别的序列号，如下图所示：

算法产生的是一个long型 64 比特位的值，第一位未使用。接下来是41位的毫秒单位的时间戳，我们可以计算下：

2^41/1000*60*60*24*365 = 69

也就是这个时间戳可以使用69年不重复，这个对于大部分系统够用了。

很多人这里会搞错概念，以为这个时间戳是相对于一个我们业务中指定的时间（一般是系统上线时间），而不是1970年。这里一定要注意。

10位的数据机器位，所以可以部署在1024个节点。

12位的序列，在毫秒的时间戳内计数。支持每个节点每毫秒产生4096个ID序号，所以最大可以支持单节点差不多四百万的并发量，这个妥妥的够用了。

优点：可以说是分布式场景下生成全局唯一ID的一种经典算法吧，采用Java生成，对于咱们Java的小伙伴来说可以说是相当接地气的了；

缺点：目前倒没发现有啥缺陷，如果硬要说有，那就是“时钟回播”的问题了。

**TIPS：**时钟回拨问题

UidGenerator，时间递增（传统的雪花算法实现都是通过System.currentTimeMillis()来获取时间并与上一次时间进行比较，这样的实现严重依赖服务器的时间。而UidGenerator的时间类型是AtomicLong，且通过incrementAndGet()方法获取下一次的时间，从而脱离了对服务器时间的依赖，也就不会有时钟回拨的问题）（https://zhuanlan.zhihu.com/p/77737855）
leaf 5ms内等待，如果时钟回拨超过5ms，依然会抛出异常。（https://www.jianshu.com/p/bd6b00e5f5ac）
sharding jdbc直接拒绝