使用UUID生成唯一id真的是唯一的吗？

发布于 2024-11-02 17:48:42 字数 246 浏览 1 评论 0原文

我想生成唯一的ID，就像java中的自动增量一样。所以之前我使用了当前的纳秒，但由于两个数据在同一纳秒内出现，所以我最终遇到了冲突。 UUID能解决上述问题吗？

注意:: 在我的项目中，我什至可以每分钟获取 10000 行记录，我会将这些记录与 UIDS 一起转储到表中。并且可能存在我会停止我的产品并在一段时间后重新启动它的情况....那么在这种情况下，UUID 类如何澄清以前生成的 Uids（我存储在数据库中）和将要创建的新 Uid（尚未转储到数据库中）？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

有深☉意 2024-11-09 17:48:42

虽然不能保证 UUID 是唯一的，但重复的概率极低。请参阅随机 UUID 重复概率。

对于您的应用程序，使用 UUID 是有意义的，但您可能希望处理极其罕见的情况，以防万一。

回复收藏 0 原文

信愁 2024-11-09 17:48:42

我严重怀疑你在同一纳秒内获得两条记录，因为调用 System.nanoTime() 需要超过 100 ns。您的时钟很可能没有纳秒精度。

但是，如果重新启动服务器，则可能会重复 nanoTime()。

解决这个问题的一种方法是使用

AtomicLong counter = new AtomicLong(System.currentTimeMillis()*1000);

long id = counter.incrementAndGet();

// something like ctz9yamgu8
String id = Long.toString(counter.incrementAndGet(), 36);

这将在应用程序重新启动时启动一个计数器，并且它们在重新启动之间不会重叠，除非您每秒维持超过一百万个 ID。（在实例的生命周期内）

注意：这仅适用于每个实例。多个服务器需要使用不同的方法。

I seriously doubt you get two records in the same nano-second as making the call System.nanoTime() takes over 100 ns. It is more likely your clock doesn't have nano second accuracy.

However, if you restart your server, you can get repeating nanoTime().

One way around this is to use

AtomicLong counter = new AtomicLong(System.currentTimeMillis()*1000);

long id = counter.incrementAndGet();

// something like ctz9yamgu8
String id = Long.toString(counter.incrementAndGet(), 36);

This will start a counter when the application restarts and they will not be overlap between restarts unless you sustain over one million ids per second. (Over the life of the instance)

Note: this only works for on a per instance basis. Multiple servers need to use a different approach.

回复收藏 0 原文

旧时光的容颜 2024-11-09 17:48:42

此页面上似乎对 UUID 的性质有些混淆。

研究维基百科页面。您将看到有不同的UUID 版本。

你问：

UUID能解决上述问题吗？

是的，UUID 值确实可以解决您的问题。

空间和时间中的一个点

原始的版本 1 代表一个点在空间和时间上，永远不会重复。

版本 1 通过使用生成它的计算机的 MAC 地址（一个点在太空中）。为此，它结合了当前时刻。添加任意数字，当注意到计算机时钟发生变化时该数字就会增加。由于计算机具有内置电池和与时间服务器的网络连接，时钟不再是一个大问题。通过将这些结合起来，实际上就不存在碰撞的可能性。

由于担心跟踪和泄露 MAC 地址和时刻所涉及的安全和隐私问题，有些人可能不想使用此版本。例如，Java 忽略从其 UUID 类。

仅供参考，更强大的数据库服务器（例如 Postgres）可以生成包括版本 1 在内的 UUID 值。您可以选择在数据库服务器上而不是在应用程序中生成 UUID。

随机

一个常用的版本是版本 4，其中 122 个 <生成 href="https://en.wikipedia.org/wiki/128-bit_computing" rel="nofollow noreferrer">128 位随机的。如果使用加密强度强的随机生成器，这是非常有效的。该版本的冲突几率比版本 1 高得多。但对于大多数实际场景，基于随机的 UUID 是完全可靠的。