如果在設備上而不是在服務器上生成，UUID4有多獨特？

Question

This question在一般意義上回答它，並沒有指定如果UUID生成不集中會發生什麼。

我最近看到了一種架構，其中所有設備（1M + ios和android）都生成UUID4密鑰（使用它們自己的生成器函數/庫），同步時這些密鑰在服務器的數據庫中被標記爲唯一。我擔心，由於大約一百萬臺設備會嘗試在本地生成，碰撞的機會將高於上述問題中描述的情況。

我之前使用過集中式UUID，但是對於這種類型的分佈式系統來說是新的，所以我採用了一個素數生成器的類比，在不同的環境中並行運行，這會使最終結果不是主要/唯一的。如果我的理解錯誤，請糾正我。

此外，請在分佈式環境中分享任何有關gotcha's和使用UUID的優秀文章。

編輯：此回答與Python UUID generation有關碰撞和使用UUID1而不是UUID4的討論。我想知道是否有任何文件證實這與Android和iOS設備的隨機性。而且，我應該如何計算/估計碰撞的概率。

Answer 1

UUID的全部重點就在於它 - 普遍獨一無二。

UUID通常基於設備的MAC地址和時間戳等事情。每秒產生幾個UUID的設備數量不會有任何衝突。

除非蘋果或谷歌搞砸他們的實施生成UUID，你沒有什麼可擔心的。

此外，UUID的全部重點在於，您不需要一箇中央的單一服務器來生成所有ID。

您鏈接問題的許多答案都包含有關UUID算法的詳細信息。這個問題與UUID生成集中無關。

更新 - 因爲重點是UUID4，這裏距離Wikipedia article about the probability of duplicates for UUID4的摘錄：

爲了把這些數字變成角度看，給定人的年度風險被隕石擊中，估計是一個機會在170億，[4]這意味着概率大約爲0.00000000006（6×10-11），相當於每年創造幾十萬億UUID的機率，並且有一個重複。換句話說，只有在接下來的100年內每秒產生10億個UUID之後，創建一個副本的概率將大約爲50％。

但是，這些概率僅在使用足夠的熵生成UUID時纔有效。否則，重複的可能性可能會更高，因爲統計分散可能更低。在分佈式應用程序需要唯一標識符的情況下，即使合併來自多個設備的數據，UUID也不會發生衝突，因此每個設備上使用的種子和生成器的隨機性在應用程序的生命週期中必須可靠。在不可行的情況下，RFC4122建議使用名稱空間變體。

根據我對iOS的使用經驗，iOS使用的是UUID4。鑑於上述情況，我不擔心任何碰撞。