流行的分布式全局唯一ID解决方案

　　唯一ID的设计在我们系统的开发中是非常重要的，几乎所有的系统设计都离不开ID编码，如电商订单编号、快递单号等。良好的ID编码设计能提高数据存储和检索的效率，便于分布式系统的部署。
　　常用分布式ID算法
　　这里我们对常用的几种ID编码方式进行整理和对比，以作抛砖引玉，相关算法对应不同编程语言的实现，网上都可以找到很多例子。
　　雪花算法
　　雪花算法（Snowflake），twitter公司内部分布式项目采用的ID生成算法，目前广受开发者的欢迎，所以这里做下简单介绍。
　　雪花算法 ID的64位二进制结构如下：
　　Snowflake的64位二进制结构第一段1位为未使用，永远固定为0。  第二段41位为毫秒级时间(41位的长度可以使用69年)。  第三段10位为WorkerId(10位的长度最多支持部署1024个节点）。  第四段12位为毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）。
　　业务中我们可以64位二进制 转换成十进制长整型的形式。因为根据时间生成，所以它是有序的，数据检索性能高。
　　ID示例：27206497290486784
　　优点：
　　1、不依赖系统或者数据库。
　　2、性能好，稳定性高。
　　缺点：
　　1、时钟回拨：强依赖机器时间，如果机器上时钟修改回调，也有可能会导致主键重复的问题。
　　2、手动配置：WorkerId（机器ID）是需要部署时手动配置的，而且WorkerId不能重复，这在项目部署的时候需要特别注意。
　　UUID / GUID
　　UUID（Universally Unique Identifier）通用标识码，GUID（Globals Unique Identifiers）全球唯一标识符。 UUID 是一种标准，GUID 是 UUID 的实现之一。UUID编码结构如下：
　　UUID格式结构1~8位采用系统时间，在系统时间上精确到毫秒级保证时间上的唯一性。  9~16位采用底层的IP地址，在服务器集群中的惟一性。  17~24位采用当前对象的HashCode值，在一个内部对象上的惟一性。  25~32位采用调用方法的一个随机数，在一个对象内的毫秒级的唯一性。
　　ID示例：652b83c2-e18b-41d4-a266-55f63d12df0
　　优点：降低全局节点的压力，使得主键生成速度较快。跨服务器合并数据方便。
　　缺点：UUID占用16个字符，空间占用较多。不是递增的有序数字，数据写入IO随机性大，因此检索效率会有所降低。
　　Redis自增
　　当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR 和 INCRBY 来实现。
　　优点： 依赖于数据库，灵活方便，且性能优于数据库。 数字ID天然排序，对分页或者需要排序的结果很有帮助。
　　缺点： 如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。 需要编码和配置的工作量比较大。
　　数据库的主键自增
　　简单易实现，比较常用的ID生成方式，利用数据库自身的主键自增功能实现。
　　优点：INT和BIGINT类型占用空间较小。主键自动增长，IO写入连续性好。数字类型查询速度优于字符串。
　　缺点：并发性能不高，受限于数据库性能。分库分表，需要改造，复杂。自增有规律，会导致数据泄露。
　　其他分布式ID
　　1、滴滴 TinyID
　　Github地址：GitHub - didi/tinyid: ID Generator id生成器 分布式id生成系统，简单易用、高性能、高可用的id生成系统
　　2、百度 UidGenerator
　　Github地址：GitHub - baidu/uid-generator: UniqueID generator
　　3、美团 Leaf
　　Github地址：GitHub - Meituan-Dianping/Leaf: Distributed ID Generate Service
　　4、数据库集群模式
　　采用数据库集群的模式，对数据库自增ID进行扩充。
　　5、基于数据库的号段模式
　　为从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 [1,1000] 代表1000个ID，具体的业务服务将本号段，等这批号段ID用完，再次向数据库申请新号段。
　　总结
　　以上就是常用的分布式全局唯一ID的解决方案，ID编码方式的选择需要根据数据存储空间的大小要求、数据检索效率高低的要求，还有是否易于系统移植的要求去作出选择，每一种编码方式都不完美，我们需要根据自身业务实际情况，去动态地选择调整。