会话 ID、UUID 和 GUID 以及一般 ID
我有一个主意。由于我不知道的原因，这可能很糟糕，但我非常感谢您对此的反馈！
我们一直在 PHP 项目中使用会话 ID。四年来第一次生成了重复的 sessionid。幸运的是，我随机决定查看客户表，因为我很无聊，注意到 sessionid 列中有重复的条目，并在任何实际问题发生之前更改了它及其引用。
这导致（或导致？）我问自己这个问题：
基本上，任何类型的 ID，无论是会话 id、uuid 还是 guid，最终都可以重复，因为它们的长度不是无限的。于是我开始思考，因为我们不想再发生这样的事情。
我想，如果我们使用日期和时间的组合作为标识符会怎么样？这不是“随机”的，但它可以解决重复问题。例如：
14th of May 2011 04:36:05PM
如果用作标识符，可以更改为：
14052011163605
这种形式的 ID 永远不会重复的原因是，未来的日期和时间组合永远不会与过去或现在的日期相同。
因为在我们的例子中，这些 ID 不应该被任何人看到，所以没有理由让它是随机的，不是吗？
我很想听听您对此的想法，以及您如何处理这种情况。生成[实际上]唯一ID 的最佳方法是什么？
I have an idea. It might be bad, for reasons not known by me, but I would really appreciate your feedback on this!
We've been using Session ID's in a PHP project. And for the first time in 4 years, a duplicate sessionid was generated. Luckily enough I randomly decided to go looking through the Customers Table because I was bored and noticed there was a duplicate entry in the sessionid column and changed it, and references to it, before any real problems occured.
Which led (or lead?) me to ask myself this question:
Basically, any type of ID, be it a session id, uuid or guid can eventually be duplicated because the length of them is not infinite. So then I got thinking, because we never want this to happen again.
I thought, What if we use a combination of date and time, as an identifier? This wouldn't be "random", but it would solve the duplication issue. For example:
14th of May 2011 04:36:05PM
If used as an identifier, could be changed to:
14052011163605
The reason this form of ID will never become duplicated is because no date, combined with time in the future will ever be the same as one in the past, or present.
And since, in our case, these ID's are not meant to be seen by anybody, there's no reason for it to be random, is there?
I'd love to hear your thoughts on this, and, how you approach situations like this. What's your best method of generating [practically] unique ID'S?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您只有一个用户，这就是事实。
If you only had one user, this would be true.
UUID / GUID 非常大（大于可见宇宙中的粒子数），
您的日期/时间解决方案将在高负载下失败。当我每秒需要 100 多个新 ID 时会发生什么？
UUID / GUIDs are very large (larger than the count of particles in visible universe)
your date/time solution will fail on high loads. what happens when i need 100+ new ids per second ?
为什么不直接将会话 ID 列设置为唯一列，然后在出现约束违规错误时生成新的会话 ID？这样数据库就会以与您基本相同的方式为您找到这个问题（而且作为奖励，它也可以修复它）。
Why not just make your session ID column a unique column, and then generate a new session ID if you get a constraint violation error? That way the database will find this problem for you in basically the same way that you did (and as a bonus, it can fix it too).
UUID 已根据纳秒时间间隔生成（请参阅此 wikipeida 文章）。如果您使用 PHP，我建议您在本页查看如何根据您的使用情况生成不同版本：
http://php.net/manual/en/function.uniqid.php
您无法保证唯一性的原因是您最终必须为包含 UUID 的实际字符串/变量选择大小限制，因此始终有可能出现重复。不过，考虑到 UUID 的可能性有很多，这实际上是不可能的。
我同意其他海报......这可能不应该发生。您实际上是如何生成唯一 ID 的？您确定您的代码正确创建了它们吗？
UUIDs are already generated based on nanosecond intervals of time (see this wikipeida article). If you are using PHP, I'd suggest this page to take a look at how to generate the different versions, depending on your use:
http://php.net/manual/en/function.uniqid.php
The reason you can't guarantee uniqueness is that you have to eventually pick a size limit for the actual string/variable containing your UUID, so there is always the potential for a duplicate. Given the number of possibilities for a UUID, though, this should be practically impossible.
I agree with the other posters... this probably shouldn't ever happen. How are you actually generating unique IDs? Are you sure your code is properly creating them?