2019獨角獸企業重金招聘Python工程師標準>>>

?訂單服務這種流量比較大的服務，可以得知部署的服務器，一般都是幾個的，掛了一個還有一個哈，最好讓轉發請求的服務器，在得知服務掛了以后不會裝發請求過來，風險更低一些啦。訂單，首先考慮的是訂單號，怎么在分布式環境下生成一個唯一的訂單號，當然還可能是分庫分表的，最好是有序的。? ?????所以使用數據庫自增就不可能啦，當然你可以單獨建個表，用事務，鎖什么的獲取唯一的訂單號，當然這個爆了或者服務垮掉，就完蛋啦，單點故障。類似的還有其他可以存數據的服務，比如zookeeper，雖然這可以建個集群，我YY一下，感覺集群又要保證數據一致性，這效率也不會太高吧。

????還有一個用java的UUID，生成倒是方便，不僅長，而且長得好難看呀，假如你是用戶，看到自己的訂單頁面這么一個訂單號，傻眼了吧。UUID是指在一臺機器上生成的數字，它保證對在同一時空中的所有機器都是唯一的，這個我還是也比較好奇，是怎么做到的，不過，它不是今天的主角，而且這個是無序的,一般有些服務還考慮冷熱數據的區分，一般老說訂單系統，老訂單一般也沒什么大用啦，遷移走也是不錯的，根據創建時間也行。

????網上說twitter的SnowflakeIdWorker算法不錯，那下載一個實現來看看

???這個中文介紹還挺不錯，寫的很明確，簡單給我們展現的是生成的ID的組成，總共是64位，最高位代表著正負，訂單還能有負的？當然不能，所以第一位當然是0啦，中間的41位去的是當前時間-開始時間戳的差值（指定）

可想而知，能使用的年限是有限的，還是希望可以這個程序可以活這么久吧，10位機器位，其中包括5位datacenterId和5位workerId，這個在啟動的時候可以初始化不同的機器位（配置不同的datacenterId和5位workerId，這個機器位的配置也可以是一個服務，重要是與眾不同），可以部署1024個節點，而且不需要其他服務，這點很爽。

還有12位是用來是毫秒內的計數，支持單個節點同一秒內可以生成4096ID，啊，你會問當個節點毫秒內超過了4096怎么辦，其實這個是對某一秒是加鎖的，超過了4096只能等下一秒啦。

? ? ?一個類，總要先看看他的構造函數

??可以看到只是對這兩個數據做了做了一個約束，因為大了也放不下哈，來看看獲取ID的主要方法。

?這邊可以看到這里加了同步鎖，當然不同節點都是不同的鎖，方法內先是獲取當前時間，然后當前時間和上一次執行的的時間作比較，雖然做了一個時間回退的判斷的，不過我先把系統時間回退，再去生成訂單，這樣還是會重復的，看來系統時間是個很關鍵的東西，那么系統時間怎么保證準確呢？

????然后看看計數器的處理，如果在同一個毫秒內，那么計數器加一，超過了4096就要等下一毫秒，時間戳改變，計數器置0。

???獲取下一毫秒的處理邏輯是這樣的，雖然有個while操作，我想也是很快的吧。

???最后做了移位和或操作

?讓我們來看看數據吧

好啦，看到了我們想要的！

?

圖片帶有微信標志，是因為我先在微信公眾號上寫了 復制過來

轉載于:https://my.oschina.net/u/2277632/blog/1511458

總結

以上是生活随笔為你收集整理的窥探SnowflakeIdWorker之并发生成唯一ID的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。