| |
首页 淘股吧 股票涨跌实时统计 涨停板选股 股票入门 股票书籍 股票问答 分时图选股 跌停板选股 K线图选股 成交量选股 [平安银行] |
股市论谈 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
商业财经 科技知识 汽车百科 工程技术 自然科学 家居生活 设计艺术 财经视频 游戏-- |
天天财汇 -> 科技知识 -> UUID真的是全球唯一吗? -> 正文阅读 |
|
[科技知识]UUID真的是全球唯一吗? |
[收藏本文] 【下载本文】 |
32位uuid,数据库每一条uuid都是全球唯一吗 |
全球唯一性属于分布式一致性问题,理论上无解。 但是我们写代码是为了解决问题的,不是用来钻牛角尖的…… |
不是。 不过,它的冲突概率是很低的。 低到什么程度呢? 首先纠正一点:UUID并不是32位,那叫32位16进制数字,或者叫128位二进制。习惯上我们会说它长128位而不是32位。 128位二进制的可能取值有2^128个,或者3.4X10^38个。 这个数字你可能无法直观的知道它有多大。那么,地球物质的总原子数大约是10^50这个数量级;每个人类细胞大约有10^14到10^17个原子。 人类身体中的一个细胞有多少个原子(不分种类原子,是原子就行了)?5 关注 · 1 回答问题 如果你能把地球打碎成和人体细胞一样大的颗粒,再把它摊开、摊成薄薄的一层——比你的头发丝还要薄得多——使得每个细胞颗粒都不会堆叠在另一个之上;然后从空间站往下扔针。 假设你扔的针会等概率的扎中每一个细胞,那么uuid冲突的概率就相当于你从空间站扔的针两次扎中了同一个细胞。 或者,换一个说法:假设你在耳朵上打了个眼准备戴耳环,头顶一架飞机飞过,然后有人从飞机上扔了一根针。这根针刚刚好穿过你耳朵眼的概率,都要比uuid冲突的概率大几万万万亿倍(懒得算了,只少不多)。 因此,uuid虽然并不是全球唯一的、的确有可能存在冲突;但对地球人来说,完全可以在工程上认为它就是唯一的。 哪怕人类使用它上亿年,只要我们还是个离不开太阳系的土炮文明,那么基本上就不用考虑uuid冲突的可能。 |
https://en.wikipedia.org/wiki/Universally_unique_identifier?en.wikipedia.org/wiki/Universally_unique_identifier 摘抄一下: In the case of standard version-1 and version-2 UUIDs using unique MAC addresses from network cards, collisions are unlikely to occur 因为UUID V1和UUID V2使用了网卡物理地址,冲突不可能存在。(理论上网卡带有唯一得mac地址。前提是网卡的物理地址不是手动设置的,不是程序自动随机生成的,不是买的山寨网卡(或者主板)) hash-based version-3 and version-5 UUIDs, and random version-4 UUIDs, collisions can occur even without implementation problems 基于Hash算法的V3和V5,基于随机数的V4,冲突可能会发生。 Thus, the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion. 因此,在103万亿个V4 UUID,找到2个重复UUID的概率为十亿分之一。 |
UUID不是32位的,现在的开发都这样不专业了吗,位和字节数字符数分不清的吗? UUID是128位,每8位用一个十六进制的字符表示,32个字符而已。 理论来说没有任何事物是全球唯一的,只有重复的概率有多高。 UUID 128位,也就是2的128次方分之一的重复概率,2^128是我们碳基生物目前想象不出来的大。 微软之前有一篇文档,描述UUID重复的概率和地球跟太阳相撞的概率差不多。 |
不是,但是你的数据库里面肯定是唯一的 |
是基于契约精神唯一,而不是技术实现的唯一。 |
uuid还真不如雪花ID,虽然解决了唯一问题,但是缺点也很明显。 缺点一、没办法排序,两次生成的ID没有顺序。 缺点二、uuid的长度太长,存储和展示都不怎么方便。 当然雪花ID你只要注意时间回溯问题,就是目前为止最完美的唯一ID。 雪花ID的优点如下: 优点一、拥有像uuid一样的唯一特性即使分布式系统也无重复。 优点二、解决了uuid不能排序的问题,新ID即使在不同的电脑上生成永远比旧ID大。 优点三、固定长度,长度比uuid短 |
这么说吧你使用uuid重复的概率 等于你一天给雷劈了5次,并且你还活着 你纠结这个纯粹浪费时间 |
认真的说,不是唯一的。有可能会相同,不过这个相同的概率是很低很低的,可以认为是唯一的。 |
|
公众号:疾风追马 前言 有一次面试,面试官问我 UUID 会不会重复,我当时只知道 UUID 是通用唯一识别码,既然是唯一,那肯定就不会重复呀。事实证明当前的我还是太年轻了,今天就来一次讲清楚 UUID 的知识。 正文什么是 UUID? 通用唯一识别码(英语:Universally Unique Identifier,缩写:UUID)是用于计算机体系中以识别信息的一个 128 位标识符。 UUID 按照标准方法生成时,在实际应用中具有唯一性,且不依赖中央机构的注册和分配。UUID 重复的概率接近零,可以忽略不计。 因此,所有人都可以自行建立和使用 UUID,而且几乎可以确定其不会与既有的标识符重复。也因为如此,在不同地方产生的 UUID 可以使用于同一个数据库或同一个频道中,而且几乎不可能重复。 UUID 的应用相当普遍,许多计算平台都提供了对于生成和解析 UUID 的支持。 这是百科里关于 UUID 的描述,大多数人对于 UUID 的理解可能也就到这里了,但是为什么是重复概率接近零,而不是绝对不会重复呢?UUID 的版本 UUID 目前标准版中有 5 个版本,这里版本的意思,其实就是生成规则,不同版本生成规则不同。 版本 1 的 UUID 是根据时间和节点 ID(通常是 MAC 地址)生成; 版本 2 的 UUID 是根据标识符(通常是组或用户 ID)、时间和节点 ID 生成; 版本 3、版本 5 透过对命名空间(namespace)标识符和名称进行散列生成确定性的 UUID; 版本 4 的 UUID 则使用随机性或伪随机性生成。 如何识别 UUID 的版本 |
|
这是版本 4 的 UUID,第二个-后第一位就是他的版本号啦~ Java 中的 UUID
java 中的 UUID 类位于 java.util 包下 randomUUID 这个方法是类型 4 的随机数生成的,也是我们最常用的 nameUUIDFromBytes 这个则是类型 3 基于名称生成的 我们来通过代码验证一下
用 nameUUIDFromBytes 这个方法,如果传入的字符数组相同,那么生成 UUID 也会相同 而用 randomUUID 这个方法则不会生成相同的 UUID 冲突概率 UUID 的标准型式包含 32 个 16 进制数字,以连字号分为五段,形式为 8-4-4-4-12 的 32 个字符。示例:550e8400-e29b-41d4-a716-446655440000 因为是 16 进制,每个位置有 16 种情况,共 32 个字符,理论上能生成不重复的结果总共有 16^32=2^128 种,约等于 3.4 x 10^38 这是一个非常非常大的数字,想想看,一亿也只是 10^8 我们再来计算冲突的概率 假设已经生成了 1 个 UUID,那么下一次生成发生冲突的概率是 1/3.4 x 10^38 假设已经生成了 2 个 UUID,那么下一次生成发生冲突的概率是 2/3.4 x 10^38 ... 随着我们已经生成的 UUID 不断变多,下次发生冲突的概率也在不断变大,但是因为总量实在太大,所以尽管概率一直在变大,也可以完全忽略不计 总结 严谨来讲,UUID 可能会发生冲突,因为总量大,发生冲突的可能性极小,可以忽略不计 优点: 本地生成 ID,不需要进行远程调用,没有网络耗时简单快速,没有性能上限 缺点: 可读性差长度过长,生成的 UUID 通常是 36 位 (包含 -),不适合作为数据库主键,如果作为主键,二级索引 (非主键索引) 会占用很大的空间。无法保证趋势递增,在 MySQL 的 InnoDB 引擎下,新插入数据会根据主键来寻找合适位置,会导致频繁的移动、分页增加了很多开销。 |
使用了 mac 地址的 uuid,是全球唯一。 但如果别人故意来用你的 mac 地址来创建 uuid, 是不是唯一,就不好说了。 反正,如果是我自己写的程序、自己能控制的若干服务器,这个范围内,uuid 真的可以唯一。 其实,提起 uuid 全球唯一,没有意义。 毕竟,与别人做软件系统接口时,你不能把你的 uuid 发给他,那样对方认不了。 |
大部分uuid构成: Mac地址+时间戳+自增序列 前两个都可以修改,自增序列在不同机器本身就无法保证唯一。没有绝对的唯一,满足业务就可以了。近期做分布式数据库mycat_plus,正准备整理一篇UUID文章,欢迎关注mycat_plus专栏:https://zhuanlan.zhihu.com/c_177209637 |
这问法有问题,我复制一条不就不唯一了? 即使是生成过程,也很难说严格唯一的 限量款而已 |
UUID 通用唯一识别码(英语:Universally Unique Identifier,缩写:UUID) UUID 的 16 个 8 位字节表示为 32 个十六进制(基数16)数字,显示在由连字符分隔 '-' 的五个组中,"8-4-4-4-12" 总共 36 个字符(32 个字母数字字符和 4 个连字符) UUID结构分解 以UUID版本1为例 示例:58e0a7d7–eebc–11d8-9669-0800200c9a66 前3段分别由Timestamp的低、中、高和UUID版本(第3段第1位)第4段Clock sequence,为避免Timestamp某些瞬间不唯一的14bits number 08:00:20:0c:9a:66 第5段NodeId为Mac地址或随机生成48bits Number优点UUID具有全局唯一性,重复UUID码概率接近零,可以忽略不计性能高使用简单,本地生成无其它消耗缺点不适合作为数据库表主键不易存储:需使用36长度字符串存储,长度过长导致索引存储过大及检索效率无序:MySQL InnoDB引擎在插入数据时会对主键进行物理排序,导致数据位置频繁变动,增加I/O开销,影响insert性能UUID V1版本 第四段使用Mac Address不安全(可用随机数替代)适应场景请求跟踪链路TraceId用户会话 sessionId一次性签名随机字符串MySQL InnoDB不推荐使用UUID主键 InnoDB使用聚簇主键索引,插入速度严重依赖插入顺序。使用UUID使得聚簇插入变得完全随机,使得数据没有任何聚集特性 UUID主键问题总结 二级索引(Secondary index 非主键索引)中必须包含主键列,如果主键列很大,其它所有索引都会很大写入目标page可能已经刷到磁盘上并从缓存中移除,或者是还没有被加载到缓存中,InnoDB在插入之前不得不先找到并从磁盘读取目标页到内存中,这将导致大量的随机I/O;因为写入是乱序的,InnoDB不得不频繁的做页分裂操作,以便为新的行分配空间。页分裂会导致移动大量数据,一次插入最少需要修改三个页而不是一个,包含两个叶子节点和一个父节点。由于频繁的页分裂,页会变得稀疏并被不规则的填充,所以最终数据会有碎片。由于页分裂和碎片的产生,索引占用空间也将增大Page是Innodb存储的最基本结构,也是Innodb磁盘管理的最小单位优化方案 此方案只针对基于timestamp的UUID版本1有效(UUID版本在第三部分的第1位) Time-Base UUID规律第一段随时间递增变化第二段随时间递增,变化缓慢大多数情况下第四段时钟序和第五段Mac地址在单机内相当于常数优化步骤删除无用的分隔符timestamp 高低位交换并重新组合UNHEX()将16进制字符串转换为Bianry(16)MySQL 5.7
MySQL 8.0以上版本 函数UUID_TO_BIN(UUID() , swap_flag) ,作用是将UUID转换为二进制Binary(16) UUID。 第二个参数设置为1,将UUID的timestamp 第三段高位和第一段低位交换位置,能保证UUID的根据时间变化相对连续递增,对InnoDB的聚簇主键索引更友好,获得更好的性能
|
尽可能保证全局唯一。 “全球”唯一没啥探讨意义。 |
看了下答案清一色的在说碰撞概率很低,理论上确实如此,但Google搜一下就能看到各种各样神奇的碰撞案例。 对于严禁场景还是建议使用数据库自增主键。 |
自己实现的话,可以用毫秒时间戳转16进制放进UUID里面,重复概率就进一步降低... |
目前现行的UUID标准是ISO/IEC 9834-8:2014。其规定了UUID是由 版本(version)、时间、变种(variant)、时钟序列、节点(node) 组成的。 其中版本一共有5种:基于时间、DCE安全(基于时间)、基于名字(MD5)、基于随机数、基于名字(SHA-1) 然后虽然标准一开始说是说“时间”、“时钟序列”,结果基于名字的UUID这两部分外加node都是使用名字生成的,而基于随机数则都是随机生成。 而基于时间的UUID则是:node“shall”包括mac地址,而网络服务接口“usually”是host地址。 如果设备没有mac地址,那么就用随机数。 所以讨论uuid是否全球唯一要分好几种情况: 首先,如果是基于随机数的uuid,那么真的就是完全随机,唯不唯一完全看脸,虽然这个概率可以忽略不计,但是我也不能保证说把有史以来生成出的所有version4的uuid全部拿过来就一定没有一样的。 其次,基于名字的uuid,其目的就是让分布的机器可以通过相同的名字生成相同的uuid,相同就是它的目的。所以也不存在唯不唯一这个说法了。 最后,就是基于时间的uuid,也是最早的uuid标准。这种理想情况下,时间+时钟序列限定了同一台机器不可能生成相同的,而mac则限定了不同的机器不会相同,看似已经天衣无缝。 但是注意,上述只是理想情况,其实还是有可能会相同的,比如设备时间往回调了,且断电让时钟序列归零了;因为某些原因两台设备产生的node内容一样了(比如都没mac然后随机一样了,或者不合规的设备生成商),然后又恰巧同一时刻时钟序列相同……诸如此类。 不过基本来说,基于时间的uuid发生上述事情的可能基本不存在,所以可以视为全球唯一。 |
UUID(通用唯一标识符)是一个标准化的标识符系统,目的是在分布式计算环境中唯一地标识信息。UUID 的标准定义规定了其格式和生成规则,理论上来说,UUID 是全球唯一的。 |
|
UUID 是通过算法生成的 128 位数字,其中包含时间戳、节点信息、随机数等元素。标准的 UUID 使用 MAC 地址作为节点信息,以确保在本地生成的 UUID 具有全局唯一性。 然而,在实际应用中,由于 UUID 的生成方式和环境的不同,极少数情况下可能存在重复的可能性,尽管这种情况非常罕见。重复的发生可能性通常来自以下几个方面: 1.随机数重复: UUID 中包含随机数,理论上来说,即使使用强大的随机数生成器,但在极少数情况下也可能生成相同的随机数,导致 UUID 重复。 2.节点信息冲突: 在一些极端情况下,如果使用 MAC 地址作为节点信息,而网络设备或虚拟机的 MAC 地址没有正确设置或管理,可能会导致节点信息冲突,进而生成相同的 UUID。 3.不符合标准规范的生成: 在某些情况下,开发者可能使用自定义的生成方式或算法来生成 UUID,而这些自定义方式可能并未严格遵循 UUID 的标准规范,导致重复的风险。 |
|
尽管存在极少数的可能性,但在实践中,UUID 的重复概率是非常低的,足以满足大多数场景下的唯一标识需求。为了避免可能的重复,可以采用其他手段如全局唯一的数据库标识符(如自增主键)来辅助或备用。 |
|
|
看到这个问题,我想到了暴雪暗黑2的数据文件压缩编码格式。 里面对文件名的哈希,如果重复了怎么办? 下标+1 希望回答了你的问题 |
取决于生成算法 |
应该不能保证 |
神他喵得全球唯一,我都碰撞过1、2次了。。。 |
当初做的考试系统,遇到过UUID重复的,导致成绩晚出了一天。后来我搞的UUID是64位的 UU+UUID+ID,再重复我也没办法了 |
一个id搞得那么复杂真是吃饱撑着故弄玄虚!128位随机数不够就256位甚至512位!什么场景应付不了? 花那么大成本去防止一个极低概率发生的问题,还不如干脆允许问题发生,然后走错误处理方案。我们系统海量物联网设备,好几个场景都用到全局id,但128bit足够了,如果冲突就重新分配,内存操作性能也极快! |
At32 以前一批mcu就出现uuid重复的问题。害死我了。厂家还不承认 |
用自增ID,可以从理论层面完全避免不唯一问题,每次增加的ID是最大ID+1。当数据库抵达最大ID时可以重排一次所有ID,继续使用。 不知道强迫症们是否满意。 |
从数学上说,不是,因为有概率冲突,不管这个概率多小。从工程上说,在大多数场景下,是,因为概率足够小。 要想在工程上“保证”uuid没有冲突,那么通常需要做一个事后检查,比如存进数据库并且加上唯一性约束,这样即便重复了也不会对数据正确性产生冲突,无非是单个请求报错,很多时候简单重试就可以了。这样做的前提是概率足够小,不然整个系统就会被不断的重试拖垮。而uuid通常符合这一点。 uuid冲突的小概率是依赖一些假设的,比如: 1. 在单个系统内使用。这样的话即使两个不同的系统产生同样的uuid,也不会互相影响。 2. 同时生成同一个系统内uuid的机器不要太多,并且MAC地址基本可控。 我之前遇到的最常见的“uuid重复”的场景,是前端浏览器自动生成uuid来对未登录用户数量进行统计,这个一般用来做广告付费统计或者利润分成。由于uuid产生于上亿台机器,并且是不受单个公司控制的机器(MAC不能保证不重复,时间戳没法保证正确),所以单个uuid可能会发生冲突。解决方式是用多个uuid组合来表示单个用户,比如机器uuid、浏览器uuid、用户uuid等,本质上就是把uuid的长度变长,减小冲突概率直至商业上可忽略冲突概率。 |
理论上几乎是,但肯定不是! 现实中遇到过一次重复,那时候简直是惊呆了,不过仅仅是一次! |
只要是定长的,就必然不可能唯一,这是简单的数学逻辑。在实际使用中只要能满足某个概率上的不重复就可以 |
全球唯一是从工程设计上保证。uuid及其生成只是一种唯一id的编码和生成方式。如果有面试官刁难你,这边建议您直接怼,“你懂设计吗” |
UUID(通用唯一标识符)旨在能够生成全球唯一的标识符。事实上,标准的 UUID 依据的是一个非常大的数字空间,确保了它们的唯一性,即使是在没有集中式协调机制的情况下。 UUID 根据 RFC 4122 标准,它们通常是 128 位的值,有 5 种不同的版本。最常用的是版本 4,这个版本的 UUID 使用随机生成的数字,其唯一性基于随机性。由于可用的数值范围非常庞大(21222122 个可能的值,因为版本 4 UUID 有 122 个随机位),所以在理论上,生成重复的 UUID 的可能性极低。 然而,"全球唯一" 并不意味着不可能出现重复,只是在实际应用中重复发生的概率非常非常低。这种概率与宇宙中两颗星星碰撞或者某人中彩票大奖的概率相似,是可能但极不可能发生的。这种概率小到通常可以忽略不计。 不过,需要注意的是,UUID 的唯一性还取决于生成它们的算法的质量。例如,如果随机数生成器的质量不高,那么产生重复的概率可能会增加。此外,如果实现不符合标准,那么也可能会影响 UUID 的唯一性。 在实际应用中,尽管生成重复 UUID 的可能性极低,但绝对唯一性还是不能完全保证。在设计系统时,如果极端情况下的唯一性冲突会导致严重问题,你可能需要额外的逻辑来处理潜在的重复情况。 |
确实有碰撞可能,害怕碰撞就弄2个uuid拼接,两个不够就4个,总有宇宙毁灭的那一天。 |
UUID(Universally Unique Identifier),即通用唯一识别码,设计之初的宗旨就是能够让在全球范围内生成的标识符具有唯一性。在理论上,UUID的独特性得到了良好的保证,通过其算法产生的概率性冲突非常小,小到可以忽略不计。 标准的UUID基于128位数字,这意味着它拥有 2^{128} 个可能的值。将这个数字与地球上的沙粒数量相比,后者约为7.5 x 10^{18}个,可见UUID的独特性确实非常之高。可以想象如果每个人都在生成UUID,哪怕每秒钟生成1亿个UUID,要想使两个UUID碰撞,大概需要经过3600年。这个时间跨度比古埃及的金字塔还要久远。因此,在实际应用中,UUID的冲突概率是极低的。 理论上的全球唯一并不意味着绝对不会发生冲突。在极其罕见的情况下,特别是当UUID不是按照规范生成时,冲突仍然有可能发生。因此,最佳实践是在系统设计时就要考虑到这种小概率事件,并预留处理机制。 如果你指的是32位十六进制数(实际上是128位二进制),那么每一个UUID在全球范围内是唯一的。但如果真正只有32位二进制组成,则无法保证全球唯一,因为它只能提供约42亿个不同的值。 |
UUID只有2^128个,也就是10^38数量级,现在科学家估算宇宙的总粒子数是10^80,每个粒子分一个UUID不就爆了。 考虑这种事情干嘛?有意义吗?我记得在哪看到过计算机因为纯物理学的原因出bug的概率都有好像是10^-38数量级,你怎么不考虑这事。 |
|
[收藏本文] 【下载本文】 |
上一篇文章 下一篇文章 查看所有文章 |
|
|
股票涨跌实时统计 涨停板选股 分时图选股 跌停板选股 K线图选股 成交量选股 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
网站联系: qq:121756557 email:121756557@qq.com 天天财汇 |