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和雪花算法一样按照时间排序和动态分批遍历
参考链接
UUID是如何保证唯一性的
网友评论