Java 生成隨機不重複推廣碼與邀請碼的演算法實戰

Java 生成隨機不重複推廣碼與邀請碼的演算法實戰

推廣碼核心需求：不可重複、不可推測。本文分析三類主流方案並深入實作演算法法。

三大方案比較

1. 查資料庫去重：每次生成查資料庫，效率極低，不推薦。
2. 主鍵打亂/插入法：以資料庫主鍵為唯一鍵，插入隨機字元構成碼值（如 8000E0V0S1D）。需連線資料庫取主鍵，可預生成批次更新提升效率。
3. 演算法保證唯一性：本文重點。無需資料庫連線，演算法選擇當效率極高。

演算法方案實測與淘汰過程

UUID：長度過長

去除連字號後 32 字元，雖幾乎絕對不重複且支援高併發，但長度不實用。

SHA 雜湊：同樣過長

輸出長度固定且較長，淘汰。

RC4 對稱加密：長度可控但需後處理

RC4 密文長度等於明文長度。以自增數字為明文、固定金鑰加密，但原始密文含非字母數字字元，不可直接給用戶。轉 16 進制後長度加倍但可接受，然密文具連續性可被推測，且固定金鑰易破解。

改良版：金鑰使用 UUID

將金鑰改為每次生成的 UUID，密文不再具推測性，滿足不可推測需求。實測 7 位數字明文加密後轉 16 進制，生成 100 萬筆零重複，效能優異。

核心程式碼架構

// 核心邏輯：RC4 加密 + UUID 金鑰 + Hex 編碼
String plainText = String.format("%07d", sequenceNumber); // 7 位數字
String key = UUID.randomUUID().toString().replace("-", "");
String cipher = RC4.encrypt(plainText, key);
String inviteCode = bytesToHex(cipher.getBytes());

RC4 演算法網路廣泛可用，本文不贅述實作細節。關鍵在於明文用自增序列保證唯一性、金鑰用 UUID 打破規律性、Hex 編碼轉為可見字元。

方案優缺點總結

適用於高併發、大量生成、離線生成等場景。若有特殊字元集需求，可替換 Hex 為 Base62 或自訂編碼。