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

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

话不多说，咱们直接进入正题~~~

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

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

话不多说，直接进入正题，先贴张思维导图吧，总结性地概括下目前网上比较流行的几种方式（当然啦，图片来源于互联网哈，因为debug懒得去制作了！）

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

一、数据库的自增主键

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

优点：简单、便捷；

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

二、批量预生成ID

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

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

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

三、UUID的方式

简介：通用唯一识别码，这个估计众所周知啦，不作过多的介绍了！

优点：简单，直接 UUID.randomUUID().toString() 即可搞定；

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

更多请见：http://www.mark-to-win.com/tutorial/51109.html