我正在構建一個應用程序。 假設它是一個消息應用程序，並變得像WhatsApp一樣流行。對於以下情況，C＃System.Guid.NewGuid（）的安全程度如何？
將爲世界上發送的每條消息給出一個GUID。
如果世界上任何兩個GUID相等，將會有問題。
從今天起，有300億！（官方）whatsapp消息在一天內被髮送到世界各地。我正在使用C＃（Xamarin）的System.Guid.NewGuid方法來生成GUID。
由於隨機數不是真正隨機的，會出現「問題」的概率是多少？
（這個問題是別人不一樣，因爲它描述的情況是數以百萬計的人得到數十億的新的GUID每天結合。）
我喜歡從維基百科這樣一段話：
他們可能會或可能不會由隨機（或僞隨機）數字生成。從隨機數生成的GUID通常包含6個固定位（這些表明GUID是隨機的）和122個隨機位;唯一此類GUID的總數爲2122（約5.3×1036）。這個數字非常大，以至於相同數字隨機生成兩次的概率可以忽略不計;然而，其他GUID版本具有不同的唯一性屬性和概率，範圍從保證的唯一性到可能的重複。爲簡單起見，假設一致概率，如果2014年地球上的每個人擁有6億個GUID，則一次重複的概率將約爲50％。
https://en.wikipedia.org/wiki/Globally_unique_identifier
如果你是真正關心你總是有選擇和創建碰撞檢測方法的能力。例如，如果您檢測到GUID已在使用中，則只需分配一個新的隨機GUID並對其進行迭代，直到檢測不到重複爲止。可以說讓我想起哈希表。對此有性能懲罰，但只知道有一個解決方案爲您的障礙！
更新
我能理解你對隨機性的關注，但如果你考慮到它是一個結構化的算法，將在連續的時間幾乎物質分配（種）。有一個最小的問題涉及到這一點，我只是更關心使用128位值的主要解決方案的性能下降。
維基百科另外：
的GUID通常用作數據庫表的主鍵，並與通常的表具有該屬性聚簇索引。這在插入記錄時會出現性能問題，因爲完全隨機的GUID意味着記錄可能需要插入到表中的任何位置，而不是僅附加在表尾附近。
你的文章似乎完全錯過了一個GUID的設計。當碰撞檢測不可能時，使用GUID。沒有單調遞增的GUID算法，因爲它不是一個GUID，即Timestamp。時間戳不能用於CAP模型中支持AP的系統，因爲它們在CAP模型中需要C。另外，爲了解決手頭上的問題，YouTube是一個分佈式視頻信息存儲平臺。每個視頻都有一個隨機的64位ID。 – Aron
可能重複[有什麼機會得到Guid.NewGuid（）重複？]（http://stackoverflow.com/questions/8642858/what-are-the-chances-to-get-a -guid-newguid-duplicate） – MichaelMao
請不要放入像crypto這樣的隨機標籤。另外，請在發佈之前嘗試谷歌您的主題。在互聯網上幾乎每個GUID的定義都會給你你的答案。 – Aron
PS 30億不是一個大數字。 GUID足以隨機分配給宇宙中的每個原子。當你找到一種方法在宇宙中的每個原子上存儲信息時，請回來...... – Aron