https://github.com/baidu/uid-generator

 

snowflake演算法

uid-generator是基於Twitter開源的snowflake演算法實現的。

snowflake將long的64位分為了3部分，時間戳、工作機器id和序列號，位數分配如下。

其中，時間戳部分的時間單位一般為毫秒。也就是說1臺工作機器1毫秒可產生4096個id（2的12次方）。

 

原始碼實現分析

與原始的snowflake演算法不同，uid-generator支援自定義時間戳、工作機器id和序列號等各部分的位數，以應用於不同場景。預設分配方式如下。

• sign(1bit)
  固定1bit符號標識，即生成的UID為正數。

• delta seconds (28 bits)
  當前時間，相對於時間基點"2016-05-20"的增量值，單位：秒，最多可支援約8.7年（注意：1. 這裡的單位是秒，而不是毫秒！ 2.注意這裡的用詞，是“最多”可支援8.7年，為什麼是“最多”，後面會講）

• worker id (22 bits)
  機器id，最多可支援約420w次機器啟動。內建實現為在啟動時由資料庫分配，預設分配策略為用後即棄，後續可提供複用策略。

• sequence (13 bits)
  每秒下的併發序列，13 bits可支援每秒8192個併發。（注意下這個地方，預設支援qps最大為8192個）

 

DefaultUidGenerator

DefaultUidGenerator的產生id的方法與基本上就是常見的snowflake演算法實現，僅有一些不同，如以秒為為單位而不是毫秒。

DefaultUidGenerator的產生id的方法如下。

 

CachedUidGenerator

CachedUidGenerator支援快取生成的id。

基本實現原理

關於CachedUidGenerator，文件上是這樣介紹的。

在實現上, UidGenerator通過借用未來時間來解決sequence天然存在的併發限制; 採用RingBuffer來快取已生成的UID, 並行化UID的生產和消費, 同時對CacheLine補齊，避免了由RingBuffer帶來的硬體級「偽共享」問題. 最終單機QPS可達600萬。

【採用RingBuffer來快取已生成的UID, 並行化UID的生產和消費】

使用RingBuffer快取生成的id。RingBuffer是個環形陣列，預設大小為8192個，裡面快取著生成的id。

獲取id

會從ringbuffer中拿一個id，支援併發獲取

填充id

RingBuffer填充時機

• 程式啟動時，將RingBuffer填充滿，快取著8192個id

• 在呼叫getUID()獲取id時，檢測到RingBuffer中的剩餘id個數小於總個數的50%，將RingBuffer填充滿，使其快取8192個id

• 定時填充（可配置是否使用以及定時任務的週期）

【UidGenerator通過借用未來時間來解決sequence天然存在的併發限制】

因為delta seconds部分是以秒為單位的，所以1個worker 1秒內最多生成的id書為8192個（2的13次方）。

從上可知，支援的最大qps為8192，所以通過快取id來提高吞吐量。

為什麼叫藉助未來時間？

因為每秒最多生成8192個id，當1秒獲取id數多於8192時，RingBuffer中的id很快消耗完畢，在填充RingBuffer時，生成的id的delta seconds 部分只能使用未來的時間。

（因為使用了未來的時間來生成id，所以上面說的是，【最多】可支援約8.7年）

 

原始碼剖析

獲取id

RingBuffer快取已生成的id

（注意：這裡的RingBuffer不是Disruptor框架中的RingBuffer，但是藉助了很多Disruptor中RingBuffer的設計思想，比如使用快取行填充解決偽共享問題）

RingBuffer為環形陣列，預設容量為sequence可容納的最大值（8192個），可以通過boostPower引數設定大小。

tail指標、Cursor指標用於環形陣列上讀寫slot：

• Tail指標
  表示Producer生產的最大序號(此序號從0開始，持續遞增)。Tail不能超過Cursor，即生產者不能覆蓋未消費的slot。當Tail已趕上curosr，此時可通過rejectedPutBufferHandler指定PutRejectPolicy

• Cursor指標
  表示Consumer消費到的最小序號(序號序列與Producer序列相同)。Cursor不能超過Tail，即不能消費未生產的slot。當Cursor已趕上tail，此時可通過rejectedTakeBufferHandler指定TakeRejectPolicy

CachedUidGenerator採用了雙RingBuffer，Uid-RingBuffer用於儲存Uid、Flag-RingBuffer用於儲存Uid狀態(是否可填充、是否可消費)

由於陣列元素在記憶體中是連續分配的，可最大程度利用CPU cache以提升效能。但同時會帶來「偽共享」FalseSharing問題，為此在Tail、Cursor指標、Flag-RingBuffer中採用了CacheLine 補齊方式。

RingBuffer填充時機

• 程式啟動時，將RingBuffer填充滿，快取著8192個id

• 在呼叫getUID()獲取id時，檢測到RingBuffer中的剩餘id個數小於總個數的50%，將RingBuffer填充滿，使其快取8192個id

• 定時填充（可配置是否使用以及定時任務的週期）

填充RingBuffer

生成id（上面程式碼中的uidProvider.provide呼叫的就是這個方法）

填充快取行解決“偽共享”

關於偽共享，可以參考這篇文章《偽共享（false sharing），併發程式設計無聲的效能殺手》

 

PaddedAtomicLong為什麼要這麼設計？

可以參考下面文章

一個Java物件到底佔用多大記憶體？https://www.cnblogs.com/magialmoon/p/3757767.html

寫Java也得了解CPU--偽共享 https://www.cnblogs.com/techyc/p/3625701.html