使用ID生成系统,如果ID生成系统瘫痪,就会迎来一场灾难。
UUID(Universally Unique Identifier)是国际标准化组织(ISO)提出的一个概念。UUID是一个128比特的数值,这个数值可以通过一定的算法计算出来。为了提高效率,常用的UUID可缩短至16位比特。
C# 中叫 GUID(Globally Unique IDentifier)
UUID具有多个版本,每个版本的算法不同,应用范围也不同。首先是一个特例--Nil UUID--通常我们不会用到它,它是由全为0的数字组成:00000000-0000-0000-0000-000000000000
基于时间的UUID通过计算当前时间戳、随机数和机器MAC地址得到。由于在算法中使用了MAC地址,这个版本的UUID可以保证在全球范围的唯一性。但与此同时,使用MAC地址会带来安全性问题,这就是这个版本UUID受到批评的地方。如果应用只是在局域网中使用,也可以使用退化的算法,以IP地址来代替MAC地址--Java的UUID往往是这样实现的(当然也考虑了获取MAC的难度)。
DCE(Distributed Computing Environment)安全的UUID和基于时间的UUID算法相同,但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。
基于名字的UUID通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了:相同名字空间中不同名字生成的UUID的唯一性;不同名字空间中的UUID的唯一性;相同名字空间中相同名字的UUID重复生成是相同的。
根据随机数,或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的,但随机的东西就像是买彩票:你指望它发财是不可能的。
和基于名字的UUID算法类似,只是散列值计算使用SHA1(Secure Hash Algorithm 1)算法。
缺点:
不易于存储:UUID太长,16字节128位。(这个相信大多数人都可以接受 long是8字节,GUID是16字节)
不易比较大小:由于UUID是根据系统时间,IP地址,HashCode,随机数创建的 根本无法保障大小是否正确。
信息不安全:基于MAC地址生成UUID的算法会造成MAC地址泄露,这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。(这个也可以接受,你的服务器地址暴露了又有什么严重的事情呢?)
1.关于大家经常说的索引查询慢?!
实际上我拿UUID查询五十条数据的时候速度极快,跟表的设计思路有关。
可能会因为16字节大,有一些微乎极微的影响,难道你不做分页吗?
我觉得100条是顶头了。除非在做数据迁移。不过真到了那个时候一点一点迁移呗。
我们建表时一定要尽量做到单表查询。且字段里的值不要过于太大。
UUID(Universally Unique Identifier)全局唯一标识符,定义为一个字符串主键,采用32位数字组成,编码采用16进制,定义了在时间和空间都完全惟一的系统信息。
UUID的编码规则:
1)1~8位采用系统时间,在系统时间上精确到毫秒级保证时间上的惟一性;
2)9~16位采用底层的IP地址,在服务器集群中的惟一性;
3)17~24位采用当前对象的HashCode值,在一个内部对象上的惟一性;
4)25~32位采用调用方法的一个随机数,在一个对象内的毫秒级的惟一性。
通过以上4种策略可以保证惟一性。在系统中需要用到随机数的地方都可以考虑采用UUID算法。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。