天天财汇 购物 网址 万年历 小说 | 三峰软件 小游戏 视频
TxT小说阅读器
↓小说语音阅读,小说下载↓
一键清除系统垃圾
↓轻轻一点,清除系统垃圾↓
图片批量下载器
↓批量下载图片,美女图库↓
图片自动播放器
↓图片自动播放,产品展示↓
首页 淘股吧 股票涨跌实时统计 涨停板选股 股票入门 股票书籍 股票问答 分时图选股 跌停板选股 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

/**
     * Static factory to retrieve a type 4 (pseudo randomly generated) UUID.
     *
     * The {@code UUID} is generated using a cryptographically strong pseudo
     * random number generator.
     *
     * @return  A randomly generated {@code UUID}
     */
    public static UUID randomUUID() {
        SecureRandom ng = Holder.numberGenerator;

        byte[] randomBytes = new byte[16];
        ng.nextBytes(randomBytes);
        randomBytes[6]  &= 0x0f;  /* clear version        */
        randomBytes[6]  |= 0x40;  /* set to version 4     */
        randomBytes[8]  &= 0x3f;  /* clear variant        */
        randomBytes[8]  |= 0x80;  /* set to IETF variant  */
        return new UUID(randomBytes);
    }

    /**
     * Static factory to retrieve a type 3 (name based) {@code UUID} based on
     * the specified byte array.
     *
     * @param  name
     *         A byte array to be used to construct a {@code UUID}
     *
     * @return  A {@code UUID} generated from the specified array
     */
    public static UUID nameUUIDFromBytes(byte[] name) {
        MessageDigest md;
        try {
            md = MessageDigest.getInstance("MD5");
        } catch (NoSuchAlgorithmException nsae) {
            throw new InternalError("MD5 not supported", nsae);
        }
        byte[] md5Bytes = md.digest(name);
        md5Bytes[6]  &= 0x0f;  /* clear version        */
        md5Bytes[6]  |= 0x30;  /* set to version 3     */
        md5Bytes[8]  &= 0x3f;  /* clear variant        */
        md5Bytes[8]  |= 0x80;  /* set to IETF variant  */
        return new UUID(md5Bytes);
    }

java 中的 UUID 类位于 java.util 包下
randomUUID 这个方法是类型 4 的随机数生成的,也是我们最常用的
nameUUIDFromBytes 这个则是类型 3 基于名称生成的
我们来通过代码验证一下

UUID uuid1 = UUID.nameUUIDFromBytes(new byte[]{'a', 'b', 'c'});
System.out.println("uuid1 = " + uuid1);
UUID uuid2 = UUID.nameUUIDFromBytes(new byte[]{'a', 'b', 'c'});
System.out.println("uuid2 = " + uuid2);
UUID uuid3 = UUID.randomUUID();
System.out.println("uuid3 = " + uuid3);
UUID uuid4 = UUID.randomUUID();
System.out.println("uuid4 = " + uuid4);
uuid1 = 90015098-3cd2-3fb0-9696-3f7d28e17f72
uuid2 = 90015098-3cd2-3fb0-9696-3f7d28e17f72
uuid3 = 2fd31523-bffb-4a7d-8cb9-a8b9c398822e
uuid4 = af06ce71-6da4-4fdc-bc2b-096c99dbaba5

用 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

SET @ori_u = UUID();
SET @u = REPLACE(@ori_u,'-','');
INSERT INTO uuid_test (id) VALUES (UNHEX(CONCAT(SUBSTR(@u, 15, 4),
                                                SUBSTR(@u, 10, 4),
                                                SUBSTR(@u, 1, 8),
                                                SUBSTR(@u, 20, 4),
                                                SUBSTR(@u, 25))));
SELECT HEX(id) FROM uuid_test;
+----------------------------------+
| HEX(id)                          |
+----------------------------------+
| EBB63D31510A7E23C024AC1100020000 |
| EBB63D3167F6128CC024AC1100020000 |
| EBB63D31B7B69C9DC024AC1100020000 |
+----------------------------------+
-- 使用MySQL8提供的函数验证
SELECT BIN_TO_UUID(id) FROM uuid_test;
+--------------------------------------+
| BIN_TO_UUID(id)                      |
+--------------------------------------+
| ebb63d31-510a-7e23-c024-ac1100020000 |
| ebb63d31-67f6-128c-c024-ac1100020000 |
| ebb63d31-b7b6-9c9d-c024-ac1100020000 |
+--------------------------------------+

MySQL 8.0以上版本
函数UUID_TO_BIN(UUID() , swap_flag) ,作用是将UUID转换为二进制Binary(16) UUID。
第二个参数设置为1,将UUID的timestamp 第三段高位和第一段低位交换位置,能保证UUID的根据时间变化相对连续递增,对InnoDB的聚簇主键索引更友好,获得更好的性能

CREATE TABLE t (id binary(16) PRIMARY KEY);

INSERT INTO t VALUES(UUID_TO_BIN(UUID(),1));

SELECT BIN_TO_UUID(id,0) FROM t;
+--------------------------------------+
| BIN_TO_UUID(id,0)                    |
+--------------------------------------+
| 11ebb3d1-b04a-0277-b69c-0242ac110002 |
| 11ebb3d1-b0f3-c8eb-b69c-0242ac110002 |
| 11ebb3d1-b198-be16-b69c-0242ac110002 |
+--------------------------------------+

尽可能保证全局唯一。
“全球”唯一没啥探讨意义。
看了下答案清一色的在说碰撞概率很低,理论上确实如此,但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数量级,你怎么不考虑这事。
[收藏本文] 【下载本文】
   科技知识 最新文章
《消失的问界里》为什么网传华为选择大面积
特斯拉万人大裁员涉及中国市场,销售部门是
媒体报道「特斯拉一天内失去 2 个高管和 10
去年是「大模型元年」,今年会是「AI应用落
2024 年人工智能方向的就业前景怎么样?
如何评价小米汽车SU7全球首例无故抛锚?
如何评价比亚迪与大疆合作发布的车载无人机
如何看待波音「吹哨人」遗言曝光:如果我出
电动汽车为什么一下爆发了?
怎么看待华为太空宽带计划?
上一篇文章      下一篇文章      查看所有文章
加:2024-01-06 13:06:54  更:2024-01-06 13:38:24 
 
 
股票涨跌实时统计 涨停板选股 分时图选股 跌停板选股 K线图选股 成交量选股 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事
网站联系: qq:121756557 email:121756557@qq.com  天天财汇