会话 ID、UUID 和 GUID，以及普通的 ID

Question

我有一个想法，这可能是不好的，原因我不知道，但我真的很希望你能给我反馈！

我们在一个PHP项目中使用Session ID。四年来，第一次生成了一个重复的sessionid。幸运的是，我随机决定查看客户表，因为我很无聊，发现在sessionid列中有一个重复的条目，并在出现任何实际问题之前更改了它以及对它的引用。

这引导（或引领）我提出了这个问题：

基本上，任何类型的ID，无论是会话ID、UUID还是GUID，都可能最终被复制，因为它们的长度不是无限的。所以我开始思考，因为我们永远不希望这种情况再次发生。

我想，如果我们使用日期和时间的组合作为标识符，怎么样？这不会是“随机”的，但它可以解决重复问题。例如：

14th of May 2011 04:36:05PM 

如果作为标识符使用，可以更改为：

14052011163605

这种ID永远不会被复制的原因是因为未来的日期和时间与过去或现在的日期和时间不同。而且，在我们的情况下，这些ID不需要被任何人看到，所以没有理由让它随机，对吧？

我很想听听您对此的想法以及您处理这种情况的方法。生成[实际上]唯一ID的最佳方法是什么？

- Lucifer

---

当处理会话ID时，你需要稍微关注一下技术。已为你添加了PHP标签。 - undefined

你确定有1000%的把握是创建了一个重复的会话ID吗？我认为应该有一些额外的检查来防止这种情况发生，而不仅仅是随机生成器。你确定不是同一个用户从两个账户登录和退出吗？ - undefined

绝对是重复的。我正在检查项目中处理会话ID的所有代码，以防这是我们的问题，但如果是这样的话，它应该发生多次，我想。一个账户6个月前创建了，并被关联了一个会话ID。昨晚，又创建了一个新账户，而且两个会话ID完全相同。如果我没有在Navicat for MySQL中点击列标题，我可能永远都没有发现它。 - undefined

为什么你的会话会保留6个月？ - undefined

如果你这样使用它们，那它们其实并不是会话。为什么不直接使用用户ID或其哈希值呢？ - undefined

Answer 1

这种形式的身份证永远不会被复制，因为未来的日期和时间与过去或现在的日期和时间永远不会相同。

如果只有一个用户，那么这是正确的。

- ceejayoz

---

我不太确定为什么这会是不正确的，除非在同一毫秒内生成了多个ID。 - undefined

@Lucifer - 在同一毫秒内创建多个ID的机会要远远高于生成相同GUID的机会。 - undefined

Answer 2

UUID / GUID（全局唯一标识符）非常庞大（比可见宇宙中的粒子数还要多）。

在高负载情况下，您的日期/时间解决方案将失败。当我每秒需要100多个新ID时会发生什么？

- David Chan

---

我很抱歉打扰你，但是有2^128个唯一的GUID，大约是3 x 10^38 ......可见宇宙的质量约为3 x 10^54千克。 - undefined

我们真的需要为3x10^54左右的微小精度差异争论吗？ - undefined

Answer 3

为什么不将您的会话ID列设置为唯一列，如果发生约束冲突错误，生成新的会话ID呢？这样数据库基本上会以与您相同的方式找到此问题（还可以修复它，是一个额外的好处）。

- Brendan Long

---

听起来很合乎逻辑，我猜想我的创造力阻碍了我的逻辑思维过程，并决定要创造一种新的身份形式。这听起来是一个相当酷的解决方案，谢谢你！ - undefined

Answer 4

UUID是基于纳秒时间间隔生成的（请参见这个维基百科文章）。如果您使用PHP，我建议查看此页面以了解如何生成不同版本的UUID，具体取决于您的用途：

http://php.net/manual/en/function.uniqid.php

您无法保证唯一性的原因是，您必须为包含UUID的实际字符串/变量最终选择大小限制，因此存在重复的可能性。但是，考虑到UUID的可能性数量，这应该是几乎不可能发生的。

我同意其他帖子的观点......这可能永远都不会发生。您如何生成唯一ID？您确定您的代码正在正确地创建它们吗？

- hross

---

谢谢提供的信息。我仍在检查我们项目中的所有代码，以确保不是我们其中之一的错误，但经过一段时间，我已经看过、编辑过并添加了项目中的所有代码，我认为如果没有注意到问题，至少会发生多次。 - undefined