但這個框架未免有些太重了，筆者之前看到專案中生成方式是時間戳（精確到秒）+四位隨機（數字+字母）的方式，看起來簡單輕巧，但在高併發場景遇到了重複的情況，為了不改變原有的唯一id的結構，筆者把心思動在了多台機器對同一種業務，如何保證後四位隨機數不重複上，畢竟34(0到9，大寫字母排除i和o)^4大概有100w個數字，一秒併發超過100w的話只能修改原id結構中時間戳精確到毫秒，如果一毫秒併發超過100w，這大概是一秒1個億的量級，其實可以吧四位隨機字母改成6位，此時是1秒1000億的量級，暫時應該沒有業務併發量能有這個級別吧。
言歸正傳，關於如何保證多級四位字母不重複上，首先我們吧這個問題轉換成如何保證多級四位34進製的數字不重複，轉換為10進製就是如何保證多機對乙個100w以內的數字不重複。最簡單的方式當然是redis自增，但這樣每次獲取id都要連線一次redis，未免有些太過耗時
為了解決上述問題，我們可以引入atomiclong，並把1000w分成1000個數字*1000組，每個機器初始取的乙個所在組，然後本地使用atomiclong自增，我們取它與1000的餘數作為當前數字，當次數字達到999，則在redis觸發一次自增，其他情況只要atomiclong自增即可。這樣多台機器在每秒100w的id生成量以內，都不會產生重複。
最後我們聊一下同一秒內唯一id太密集的情況，對此我們可以採取已組做尾數，atomiclong*1000組合成數字的方式，並引入柵欄加密，最後打亂字母與數字順序的方式。
當然問題也有以下幾點：
1、強依賴redis，一旦redis出現問題，atomiclong達到999後，下一次生成必定失敗，並且單台機器後續吞吐量只能達到每秒1000
2、如果生產有20臺機器，其中一台機器初始化所在組後，產生網路問題導致後續請求均未到達此機器，問題修復後可能出現此機器組別與其他機器重複，導致id重複的情況
當然以上兩種情況相對都是小概率事件，同事我們還有時間戳保證id的唯一性，所以可以在很大程度上忽略此問題，最後附上核心**如下圖：
php 生成唯一ID
function guid factor prefix suffix 生成因子 機器毫秒，使用者瀏覽器與作業系統資訊，使用者ip，隨機因子,及自定義 factor 因子 原理 自定義 factor 因子 例如可使用使用者 user id 模組標識 product,order.字首 prefix 可用...
php生成唯一id
網上查了下，有很多的方法 1 md5 time mt rand 1,1000000 這種方法有一定的概率會出現重複 2 php內建函式uniqid uniqid 函式基於以微秒計的當前時間，生成乙個唯一的 id.w3school參考手冊有一句話 由於基於系統時間，通過該函式生成的 id 不是最佳的。...
MySql唯一ID生成
前陣子，一直在折騰阿里雲。寫的一些文章也放到自己的wordpress部落格上了。但自己前陣子在做系統更換操作的時候未備份磁碟，大部分心血付諸東流。真是乙個悲傷的故事。現在決定用.net搞搞自己的部落格。正好把wordpress給拋棄掉。言歸正傳，這個唯一號類似自增id，自增id雖然好用，但進行資料庫...