會話ID，UUID和GUID和一般ID的一般

我有一個想法。這可能是不好的，因爲我不知道的原因，但我真的很感激你對此的反饋！會話ID，UUID和GUID和一般ID的一般

我們已經在PHP項目中使用了會話ID。而且在4年來第一次生成了重複的sessionid。幸運的是，我隨機決定查看客戶表，因爲我感到無聊，並且注意到sessionid列中有一個重複的條目，並在發生任何實際問題之前對其進行了更改並對其進行了引用。

而導致（或導致？）我問自己這個問題：

基本上，任何類型的ID，無論是會話ID，uuid或GUID最終能夠被複制，因爲它們的長度並不是無限。於是我開始思考，因爲我們不希望這種情況再次發生。

我想，如果我們使用日期和時間的組合作爲標識符？這不會是「隨機的」，但它可以解決重複問題。例如：

14th of May 2011 04:36:05PM

如果用作一個標識符，可改爲：

14052011163605

這種形式的ID的永遠不會成爲複製的原因是因爲沒有日期，隨着時間的推移在未來組合將永遠與過去或現在一樣。

因爲在我們的情況下，這些身份證並不是任何人都可以看到的，所以沒有理由是隨機的，是嗎？

我很想聽聽你對此的想法，以及你如何處理這種情況。什麼是生成[實際上]唯一ID的最佳方法？

2011-06-01 Lucifer

當您處理會話ID時，您需要關注技術。爲您添加了PHP標籤。 – 2011-06-01 21:37:41

謝謝@Gregory – Lucifer 2011-06-01 21:39:55

您是否確定創建了重複的會話ID？我認爲還有一些額外的檢查可以防止這種情況發生，而不僅僅是隨機數發生器。你確定它不是從兩個賬戶登錄和登出的用戶嗎？ – 2011-06-01 21:40:46

UUID/GUID是非常大的

您的日期/時間解決方案將在高負載故障（比顆粒在可見宇宙的次數多）。當我需要每秒100個以上的新ID時會發生什麼？

2011-06-01 21:40:13

嘎我不想打電話給你，但有2^128獨特的GUID約3×10^38 .....可見宇宙的質量約爲3×10^54公斤。 – James 2011-06-01 21:50:25

我們真的需要嘲笑3x10^54左右的精確差異嗎？ – 2011-06-02 09:36:33

這種形式的ID永遠不會重複的原因是因爲沒有日期，與未來的時間相結合將永遠不會像過去或現在一樣。

如果你只有一個用戶，這將是真實的。

2011-06-01 21:40:20 ceejayoz

我不太清楚我明白*爲什麼這將是不真實的**，除非**在同一毫秒內生成多個ID。 – Lucifer 2011-06-01 21:54:47

@Lucifer - 在同一毫秒內創建多個ID的機會遠遠高於生成相同GUID的更改。 – 2011-06-01 22:05:43

爲什麼不只是讓您的會話ID列成爲一個唯一的列，然後生成一個新的會話ID，如果您得到一個約束違規錯誤？這樣數據庫就會以與你一樣的方式爲你找到這個問題（作爲獎勵，它也可以修復它）。

2011-06-01 21:43:32

這聽起來很合理，我想我的創意方面阻止了我的邏輯思維過程，並決定要創建一種新的身份識別形式。這聽起來像是一個很酷的解決方案，謝謝！ – Lucifer 2011-06-01 21:53:01

UUID已基於納秒的時間間隔生成（請參閱此wikipeida article）。如果您使用的是PHP，我建議這個頁面來看看如何生成不同的版本，這取決於你的使用：

你不能保證唯一性的原因是，你有最終會選擇包含您的UUID的實際字符串/變量的大小限制，因此總是有可能發生重複。但是，鑑於UUID的可能性數量，這實際上是不可能的。

我同意其他海報......這可能不應該發生。你如何真正生成唯一的ID？你確定你的代碼正確地創建它們嗎？

2011-06-01 21:45:49 hross

感謝您的信息。我仍然在我們的項目中再次檢查所有的代碼，以確保它不是我們中的一個人犯的錯誤，但是在一段時間內，我已經看到，編輯並添加到項目中的所有代碼中，我會假設如果沒有發現問題，它會至少發生一次。 – Lucifer 2011-06-01 21:51:01

回答