Question

我正在创建一个自定义算法，将信息嵌入到 timeUUID 中。在学习RFC 4122时。在规范中，版本1 UUID具有以下结构：

 0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          time_low                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       time_mid                |         time_hi_and_version   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         node (2-5)                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

我发现时间戳的下半部分（最右边的32位）位于ID的前面，使其成为排序UUID时最相关的部分。我不了解的是该规范如何在对UUID进行排序时按照创建顺序进行排序。

为说明该问题，请在此处找到两个示例，其中时间戳t1> t2，但是使用该时间戳创建的UUID的顺序相反。

 t1 = 137601405637595834 // 0x1e8dbbfd79f92ba
 t2 = 3617559227 // 0xd79f92bb

被转换为以下部分

 t1_low: Uint = 3617559226 // 0xd79f92ba
 t1_mid: Ushort = 56255 // 0xdbbf
 t1_hi: Ushort = 1e8 // 0x1e8

 t2_low: Uint = 3617559226 // 0xd79f92bb
 t2_mid: Ushort = 0 // 0x0
 t2_hi: Ushort = 0 // 0x0

由于在这种情况下最低有效字节与顺序无关，因此为简化起见，我将忽略它。

使用这些时间戳标记的UUID是

 UUID1 = d79f92ba-dbbf-11e8-8808-000000000002
 UUID2 = d79f92bb-0000-1000-a68b-000000000004

很清楚UUID1

我的分析出了什么问题？

Answer 1

UUIDv1规范故意将最大熵放入高阶位中，以使键不会像您期望的那样进行排序；取而代之的是，它们看起来像是随机的，却在整个数字范围内大致均匀地分布，而与创建顺序无关，就像UUIDv3 / v4 / v5一样。

如果需要可排序的时间戳，请添加另一列；将UUID用作除不透明标识符之外的任何东西，最终将在以后咬住您。

在实施RFC 4122时，基于时间的UUID不遵循创建顺序

1 个答案: