uuid生成_技术 | 分布式全局唯一ID生成之雪花算法

为了标识一段数据，通常我们会为其指定一个唯一id，比如数据库中的自增主键。 但是当数据量非常大时，仅靠数据库的自增主键是远远不够的。不仅是因为单表容量有限，数据库自增主键的性能也并不高。此外，某些数据库并不自带主键自增功能，需要业务代码来实现(比如Redis缓存)。 对于分布式场景，生成id时还必须考虑到全局唯一性，每台机器生成的id不能重复。而且有时我们对生成的id还有递增或连续的要求。 如果生成的id不要求递增或连续，对于简单的系统，可以直接采用随机UUID来作为id。

UUID是什么？

这串数字，其实就是一种UUID：00000000-0000-0000-0000-000000000000

UUID是通用唯一识别码(Universally Unique Identifier)的缩写，开放软件基金会(OSF)规范定义了包括网卡MAC地址、时间戳、名字空间(Namespace)、随机或伪随机数、时序等元素。利用这些元素来生成UUID，可以把它理解为一个随机的固定位数的字符串，一般为128位二进制组成，32位十六进制。 UUID有多种不同的生成策略，如Java中有四种策略。

四种不同的UUID的生成策略

1. randomly: 基于随机数生成UUID，由于Java中的随机数是伪随机数，其重复的概率是可以被计算出来的。
2. time-based:基于时间的UUID,这个一般是通过当前时间，随机数，和本地Mac地址来计算出来，自带的JDK包并没有这个算法的我们在一些UUIDUtil中，比如我们的log4j.core.util，会重新定义UUID的高位和低位。
3. DCE security:DCE安全的UUID。
4. name-based：基于名字的UUID，通过计算名字和名字空间的MD5来计算UUID。

通常，UUID的生成十分简单，使用JDK或工具包自带的方法即可。但是，使用UUID之前，要先了解他的优缺点。

UUID的优缺点？

优点

1. 本地生成，无需网络通讯，性能较高
2. 无序，不可预测，可以避免爬虫之类的攻击

缺点

1. 32位通常用String类型存储，空间占用较多
2. 不能生成递增有序的数字

综合上述优缺点，UUID的适用于 不需要担心过多的 空间占用，以及不需要生成有递增趋势的值的场景。 在Log4j里面 他在UuidPa tternConverter中加入了UUID来标识每一条日志。 如果我们需要生成递增有序的id，UUID显然是不能满足的，可以选用雪花算法来实现。 什么是雪花算法SnowFlake？ SnowFlake算法是Twitter设计的一个可以在分布式系统中生成唯一的ID的算法，它可以满足Twitter每秒上万条消息ID分配的请求，这些消息ID是唯一的且有大致的递增顺序。 官方源码仓库：https://github.com/twitter-archive/snowflake

雪花算法实现原理？

SnowFlake算法产生的ID是一个64位的整型，结构如下： 1位标识部分：在java中由于long的最高位是符号位，正数是0，负数是1，一般生成的ID为正数，所以为0； 41位时间戳部分：这个是毫秒级的时间，一般实现上不会存储当前的时间戳，而是时间戳的差值(当前时间-固定的开始时间)，这样可以使产生的ID从更小值开始；41位的时间戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年。 10位节点部分：Twitter实现中使用前5位作为数据中心标识，后5位作为机器标识，可以部署1024个节点。 12位序列号部分：支持同一毫秒内同一个节点可以生成4096个ID。 SnowFlake算法生成的ID大致上是按照时间递增的，用在分布式系统中时，需要注意数据中心标识和机器标识必须唯一，这样就能保证每个节点生成的ID都是唯一的。或许我们不一定都需要像上面那样使用5位作为数据中心标识，5位作为机器标识，可以根据我们业务的需要，灵活分配节点部分，如：若不需要数据中心，完全可以使用全部10位作为机器标识；若数据中心不多，也可以只使用3位作为数据中心，7位作为机器标识。

手动实现雪花算法

Java实现，源码位置：https://github.com/lzhpo/Snowflake-Java

Go语言实现，源码位置：https://github.com/lzhpo/SnowFlake-Golang

使用雪花算法注意事项

SnowFlake算法生成的ID大致上是按照时间递增的，用在分布式系统中时，需要注意数据中心标识和机器标识必须唯一，这样就能保证每个节点生成的ID都是唯一的。