雪花算法(Snowflake Algorithm)和 UUID(Universally Unique Identifier)都是用于生成唯一标识符的方法,但它们在实现和适用场景上存在一些区别。
雪花算法:
雪花算法是Twitter开发的一种分布式ID生成算法。
雪花算法的核心思想是在分布式环境下生成递增的、趋势递增的、唯一的64位整数。
雪花算法的生成结果由以下几部分组成:一个时间戳、一个机器ID、一个数据中心ID和一个自增序列。
适用于分布式系统中生成全局唯一的主键ID,可以保证一定的顺序性。
UUID:
UUID是一种由标准化的算法生成的128位数字,通常表现为32个十六进制数字,以连字符分隔。
UUID的生成不依赖于分布式环境,可以在任何设备上生成。
UUID的生成结果几乎可以被认为是全局唯一的,但并不能保证绝对唯一。
适用于生成在分布式和非分布式环境中唯一标识的字符串。
对于生成主键ID,两种方式都可以使用,但根据不同的需求和环境选择更合适的方式:
如果你的系统是一个分布式系统,需要生成递增的、趋势递增的、保证顺序的主键ID,那么雪花算法是更合适的选择。它可以在分布式环境下生成全局唯一的ID,并且保证一定的顺序性。
如果你的系统是一个非分布式系统,或者对顺序性要求不高,只需要生成唯一标识的主键ID,那么UUID是更简单的选择。UUID可以在任何设备上生成,并且几乎可以被认为是全局唯一的。
对于生成文件名,通常建议使用UUID。因为文件名通常不需要保证顺序性,并且UUID生成简单,不依赖于分布式环境。使用UUID作为文件名可以很好地避免冲突和重复。
UUID
UUID总长度 36,由 32 个 16 进制字符和 4 个连字符组成。连字符仅用于增加可读性,实际的精度为一个 16 进制字符为 2^4=4bit,32 个则为 32*4bit=128bit。UUID具有多个版本,每个版本的算法不同,应用范围也不同。首先是一个特例--Nil UUID--通常我们不会用到它,它是由全为0的数字组成,如下:00000000-0000-0000-0000-000000000000
- UUID Version 1:基于时间的UUID
基于时间的UUID通过计算当前时间戳、随机数和机器MAC地址得到。由于在算法中使用了MAC地址,这个版本的UUID可以保证在全球范围的唯一性。但与此同时,使用MAC地址会带来安全性问题,这就是这个版本UUID受到批评的地方。如果应用只是在局域网中使用,也可以使用退化的算法,以IP地址来代替MAC地址--Java的UUID往往是这样实现的(当然也考虑了获取MAC的难度)。 - UUID Version 2:DCE安全的UUID
DCE(Distributed Computing Environment)安全的UUID和基于时间的UUID算法相同,但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。 - UUID Version 3:基于名字的UUID(MD5)
基于名字的UUID通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了:相同名字空间中不同名字生成的UUID的唯一性;不同名字空间中的UUID的唯一性;相同名字空间中相同名字的UUID重复生成是相同的。 - UUID Version 4:随机UUID
根据随机数,或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的,但随机的东西就像是买彩票:你指望它发财是不可能的,但狗屎运通常会在不经意中到来。 - UUID Version 5:基于名字的UUID(SHA1)
和版本3的UUID算法类似,只是散列值计算使用SHA1(Secure Hash Algorithm 1)算法。
UUID的应用
从UUID的不同版本可以看出,
Version 1/2适合应用于分布式计算环境下,具有高度的唯一性;v1同一台机器,不同服务之间会重复,v2同一台机器可以通过不同的域名使不同服务也不会重复。
Version 3/5适合于一定范围内名字唯一,且需要或可能会重复生成UUID的环境下;使用v5替换v3碰撞概率更低。
Version 4,个人的建议是最好不用(虽然它是最简单最方便的,随机数重复,uuid就会重复)。
雪花算法
原始雪花算法会有时间回拨问题,业界有各种解决方案,以下是解决方案,雪花算法链接,时间回拨也不会产生重复id
总结:
如果你想让你的数据按照时间排序,或者想要分批遍历大量数据的时候可以用雪花算法和自增id,如果是需要分布式则只能选择雪花算法,uuid无法像自增id和雪花算法一样按照时间排序和动态分批遍历