Splync 的雙重識別方式：UUID 和自增整數

在 Splync 的資料庫中，每位使用者和每個專案都有兩種不同的 ID：UUID 和自增整數。自增整數是大多數人熟悉的，只是一個計數器：1、2、3，如此類推。Splync 在伺服器資料庫中使用這些整數來組織幾乎每個表格，因為它們簡單、快速且高效。然而，我們從不將這些內部編號暴露給應用程式。例如，如果你是第 42 個註冊的使用者，資料庫中的內部 ID 就是 42。但你的 iOS 應用程式從未見過 "42"。相反，應用程式使用 UUID 來代表你。我們對專案也採用相同的方法——資料庫中的專案 ID 可能是 "7"，但應用程式始終使用長 UUID 來引用它。

UUID 是全球唯一識別碼的縮寫。Splync 使用符合 RFC 4122 的版本 4，變體 1 的 UUID——這是最廣泛採用的標準之一。它是一個隨機生成的字串，看起來像 949ca11c-a6ed-48a3-b40a-fa9727494917。UUID 通常寫成 32 個十六進位字元，分為五個部分，用連字號分隔。它被設計成全球唯一，意味著即使在不同的伺服器或資料庫之間也不會衝突。從數學上來看，大約有 16^32 = 2^128 種可能的組合。然而，因為有六位元要保留用來指示變體和版本，不同的版本 4，變體 1 的 UUID 總數大約是 2^122，或約 5.3 x 10^36——這是一個天文數字，確保實際的唯一性。

每對 UUIDv4 大約有 1/5.3 × 10^36 的機會相符。這個數字小到幾乎無法在人的想像中存在。想像一下同時擲 47 個骰子。每個骰子都是 "1" 的概率大約是 1/6^47，或大約 1/3.7 × 10^36。這與 UUID 碰撞的概率在同一數量級。現在，想像地球上的每個人——大約 80 億人——每毫秒擲那 47 個骰子持續一兆年。這大約是 2.5 × 10^32 次總嘗試。即使在全部試驗之後，仍然只有萬分之一的機會有人同時擲出 47 個 1。這就是兩個 UUIDv4 碰撞的可能性有多低。這不是 "罕見"，而是宇宙級的荒誕——這種巧合足以讓數學家們放下咖啡，檢查宇宙是否出現錯誤。

乍看之下，生成 UUID 似乎很簡單——畢竟，它只是看起來隨機的字母數字串。但試著用筆和紙自己寫一個。你可以寫下 36 個字元，當然，但如果你重複這個練習數千次，明顯的模式將會出現。也許你偏愛某些數字，如 3 或 8，很少使用像 x 這樣的字母。電腦可以立即檢測到這些偏好。一個惡意的駭客可以分析你的習慣，並在一天內縮小 "隨機" 秘密字串的範圍。然後，如果你也使用電腦並調用 rand()，這個經典的隨機函數來生成每個數字。這樣雖然更好，但仍然不夠好。許多常見編程環境中的 "隨機" 數字生成器是偽隨機的，意味著它們遵循從內部種子開始的可預測數學序列，通常基於系統時間。如果有人發現或猜到了那個種子，他們就能重現你的生成器曾經產生的每個值。

完美的隨機性並不存在——就像不存在完美的骰子，或完美隨機拋擲的骰子。每個物理或數字過程都遵循一些基本規則。然而，數學家和工程師花了數十年設計演算法，使其盡可能接近真正的隨機性。當 Splync 創建新版本的 UUIDv4 時，它不僅僅是像擲骰子一樣 "隨機選擇數字"。它向操作系統請求微小的不可預測性——例如你的 CPU 完成一項任務的精確時刻、硬件內的微弱電噪聲，或記憶體中背景時間的波動。這些熵的片段被收集並混合成 128 位元的數據——一長串的 0 和 1。結果是一個幾乎不可能被應用程式用戶或潛在的惡意攻擊者猜測或重複的代碼。

Splync 使用 UUID 來處理如用戶 ID 和專案 ID 等敏感識別符，因為它們非常隨機且安全。同時，在其伺服器中，Splync 將這些 UUID 轉換為自增整數，以便在大型數據集上進行更快速的搜尋和分析。這種雙重識別方式在安全性和便利性之間取得平衡——外部隱私與內部性能。Splync 的目標是成為一個無壓力、簡單且安全的預算追踪應用程式。在看得見的 UI 背後，我們不斷完善架構，以保持流程順暢、安全和靜謐智慧。