百度uid-generator原始碼

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的方法如下。

    protected synchronized long nextId() {
        long currentSecond = getCurrentSecond();

        // Clock moved backwards, refuse to generate uid
        if
 
 (currentSecond < lastSecond) {
            long refusedSeconds = lastSecond - currentSecond;
            throw new UidGenerateException("Clock moved backwards. Refusing for %d seconds", refusedSeconds);
        }

        // At the same second, increase sequence
        if (currentSecond == lastSecond) {
            sequence = (sequence + 1) & bitsAllocator.getMaxSequence();
            // Exceed the max sequence, we wait the next second to generate uid
            if (sequence == 0) {
                currentSecond = getNextSecond(lastSecond);
            }

        // At the different second, sequence restart from zero
        } else {
            sequence = 0L;
        }

        lastSecond = currentSecond;

        // Allocate bits for UID
        return bitsAllocator.allocate(currentSecond - epochSeconds, workerId, sequence);
    }

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

   @Override
    public long getUID() {
        try {
            return ringBuffer.take();
        } catch (Exception e) {
            LOGGER.error("Generate unique id exception. ", e);
            throw new UidGenerateException(e);
        }
    }

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 補齊方式。

public class RingBuffer {
    private static final Logger LOGGER = LoggerFactory.getLogger(RingBuffer.class);

    /** Constants */
    private static final int START_POINT = -1; 
    private static final long CAN_PUT_FLAG = 0L; //用於標記當前slot的狀態，表示可以put一個id進去
    private static final long CAN_TAKE_FLAG = 1L; //用於標記當前slot的狀態，表示可以take一個id
    public static final int DEFAULT_PADDING_PERCENT = 50; //用於控制何時填充slots的預設閾值：當剩餘的可用的slot的個數，小於bufferSize的50%時，需要生成id將slots填滿

    /** The size of RingBuffer's slots, each slot hold a UID */
    private final int bufferSize; //slots的大小，預設為sequence可容量的最大值，即8192個
    private final long indexMask; 
  
    private final long[] slots;  //slots用於快取已經生成的id
    private final PaddedAtomicLong[] flags; //flags用於儲存id的狀態(是否可填充、是否可消費)

    /** Tail: last position sequence to produce */
    //Tail指標
    //表示Producer生產的最大序號(此序號從0開始，持續遞增)。Tail不能超過Cursor，即生產者不能覆蓋未消費的slot。當Tail已趕上curosr，此時可通過rejectedPutBufferHandler指定PutRejectPolicy
    private final AtomicLong tail = new PaddedAtomicLong(START_POINT); //

    /** Cursor: current position sequence to consume */
    //表示Consumer消費到的最小序號(序號序列與Producer序列相同)。Cursor不能超過Tail，即不能消費未生產的slot。當Cursor已趕上tail，此時可通過rejectedTakeBufferHandler指定TakeRejectPolicy
    private final AtomicLong cursor = new PaddedAtomicLong(START_POINT);

    /** Threshold for trigger padding buffer*/
    private final int paddingThreshold; //用於控制何時填充slots的閾值
    
    /** Reject put/take buffer handle policy */
    //當slots滿了，無法繼續put時的處理策略。預設實現：無法進行put，僅記錄日誌
    private RejectedPutBufferHandler rejectedPutHandler = this::discardPutBuffer;
    //當slots空了，無法繼續take時的處理策略。預設實現：僅丟擲異常
    private RejectedTakeBufferHandler rejectedTakeHandler = this::exceptionRejectedTakeBuffer; 
    
    /** Executor of padding buffer */
    //用於執行【生成id將slots填滿】任務
    private BufferPaddingExecutor bufferPaddingExecutor;

RingBuffer填充時機

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

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

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

填充RingBuffer

    /**
     * Padding buffer fill the slots until to catch the cursor
     */
    public void paddingBuffer() {
        LOGGER.info("Ready to padding buffer lastSecond:{}. {}", lastSecond.get(), ringBuffer);

        // is still running
        if (!running.compareAndSet(false, true)) {
            LOGGER.info("Padding buffer is still running. {}", ringBuffer);
            return;
        }

        // fill the rest slots until to catch the cursor
        boolean isFullRingBuffer = false;
        while (!isFullRingBuffer) {
            //獲取生成的id，放到RingBuffer中。
            List<Long> uidList = uidProvider.provide(lastSecond.incrementAndGet());
            for (Long uid : uidList) {
                isFullRingBuffer = !ringBuffer.put(uid);
                if (isFullRingBuffer) {
                    break;
                }
            }
        }

        // not running now
        running.compareAndSet(true, false);
        LOGGER.info("End to padding buffer lastSecond:{}. {}", lastSecond.get(), ringBuffer);
    }

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

    /**
     * Get the UIDs in the same specified second under the max sequence
     * 
     * @param currentSecond
     * @return UID list, size of {@link BitsAllocator#getMaxSequence()} + 1
     */
    protected List<Long> nextIdsForOneSecond(long currentSecond) {
        // Initialize result list size of (max sequence + 1)
        int listSize = (int) bitsAllocator.getMaxSequence() + 1;
        List<Long> uidList = new ArrayList<>(listSize);

        // Allocate the first sequence of the second, the others can be calculated with the offset
        //這裡的實現很取巧
        //因為1秒內生成的id是連續的，所以利用第1個id來生成後面的id，而不用頻繁呼叫snowflake演算法
        long firstSeqUid = bitsAllocator.allocate(currentSecond - epochSeconds, workerId, 0L);
        for (int offset = 0; offset < listSize; offset++) {
            uidList.add(firstSeqUid + offset);
        }

        return uidList;
    } 

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

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

    //陣列在物理上是連續儲存的，flags陣列用來儲存id的狀態（是否可消費、是否可填充），在填入id和消費id時，會被頻繁的修改。
    //如果不進行快取行填充，會導致頻繁的快取行失效，直接從記憶體中讀資料。
    private final PaddedAtomicLong[] flags;

    //tail和cursor都使用快取行填充，是為了避免tail和cursor落到同一個快取行上。
    /** Tail: last position sequence to produce */
    private final AtomicLong tail = new PaddedAtomicLong(START_POINT);

    /** Cursor: current position sequence to consume */
    private final AtomicLong cursor = new PaddedAtomicLong(START_POINT)

/**
 * Represents a padded {@link AtomicLong} to prevent the FalseSharing problem<p>
 * 
 * The CPU cache line commonly be 64 bytes, here is a sample of cache line after padding:<br>
 * 64 bytes = 8 bytes (object reference) + 6 * 8 bytes (padded long) + 8 bytes (a long value)
 * @author yutianbao
 */
public class PaddedAtomicLong extends AtomicLong {
    private static final long serialVersionUID = -3415778863941386253L;

    /** Padded 6 long (48 bytes) */
    public volatile long p1, p2, p3, p4, p5, p6 = 7L;

    /**
     * Constructors from {@link AtomicLong}
     */
    public PaddedAtomicLong() {
        super();
    }

    public PaddedAtomicLong(long initialValue) {
        super(initialValue);
    }

    /**
     * To prevent GC optimizations for cleaning unused padded references
     */
    public long sumPaddingToPreventOptimization() {
        return p1 + p2 + p3 + p4 + p5 + p6;
    }

}

PaddedAtomicLong為什麼要這麼設計？

可以參考下面文章

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

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