實用向—總結一些唯一ID生成方式

bigfan發表於2020-09-28
在日常的專案開發中，我們經常會遇到需要生成唯一ID的業務場景，不同的業務對唯一ID的生成方式與要求都會不盡相同，一是生成方式多種多樣，如UUID、雪花演算法、資料庫遞增等；其次業務要求上也各有不同，有的只要保證唯一性即可，有的需要加上時間戳，有的要保證按順序遞增等。以下是我結合實際業務中的使用總結了幾種唯一ID的生成方式，  要求就是在一般的應用場景下一方面能滿足一定資料量級（千萬級）的需要，另一方面使用方式相對簡單輕量，不需要過多依賴第三方，同時從併發安全、衝突率、生成效能上做了一些簡單的測試，大家可以略做參考

一、生成方式

1、UUID產生命令唯一標識，32位的字母數字組合

    /**
     * 根據UUID產生命令唯一標識
     * 
     * @throws InterruptedException
     */
    public static String getUUIDHashCode() {
        String orderSeq = UUID.randomUUID().toString();
        return orderSeq;

    }

2、UUID取hash值+隨機數，16位純數字

    /**
     * 根據UUID取hash值+隨機數，產生命令唯一標識
     * 
     * @throws InterruptedException
     */
    public static String getOrderSeq() {
        String orderSeq = Math.abs(UUID.randomUUID().toString().hashCode()) + "";
        while (orderSeq.length() < 16) {
            orderSeq = orderSeq + (int) (Math.random() * 10);
        }
        return orderSeq;
    }

3、十六進位制隨機數 ，長度16的十六進位制字串

    //十六進位制隨機數  16位的十六進位制字串
    public static String getRandomHexString() {
        try {
            StringBuffer result = new StringBuffer();
            for (int i = 0; i < 16; i++) {
                result.append(Integer.toHexString(new Random().nextInt(16)));
            }
            return result.toString().toUpperCase();

        } catch (Exception e) {
            // TODO: handle exception
            e.printStackTrace();

        }
        return null;

    }

4、雪花演算法

長度不超過20的純數字，時間戳不同，長度會產生變化

    /** 開始時間戳 */
    private final long twepoch = 1420041600000L;

    /** 機器id所佔的位數 */
    private final long workerIdBits = 5L;

    /** 資料標識id所佔的位數 */
    private final long datacenterIdBits = 5L;

    /** 支援的最大機器id，結果是31 (這個移位演算法可以很快的計算出幾位二進位制數所能表示的最大十進位制數) */
    private final long maxWorkerId = -1L ^ (-1L << workerIdBits);

    /** 支援的最大資料標識id，結果是31 */
    private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);

    /** 序列在id中佔的位數 */
    private final long sequenceBits = 12L;

    /** 機器ID向左移12位 */
    private final long workerIdShift = sequenceBits;

    /** 資料標識id向左移17位(12+5) */
    private final long datacenterIdShift = sequenceBits + workerIdBits;

    /** 時間截向左移22位(5+5+12) */
    private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;

    /** 生成序列的掩碼，這裡為4095 (0b111111111111=0xfff=4095) */
    private final long sequenceMask = -1L ^ (-1L << sequenceBits);

    /** 工作機器ID(0~31) */
    private long workerId;

    /** 資料中心ID(0~31) */
    private long datacenterId;

    /** 毫秒內序列(0~4095) */
    private long sequence = 0L;

    /** 上次生成ID的時間戳 */
    private long lastTimestamp = -1L;

 
    /**
     * 建構函式
     * @param workerId 工作ID (0~31)
     * @param datacenterId 資料中心ID (0~31)
     */
    public SnowFlake(long workerId, long datacenterId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        if (datacenterId > maxDatacenterId || datacenterId < 0) {
            throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
        }
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }

    
    /**
     * 獲得下一個ID (該方法是執行緒安全的)
     * @return SnowflakeId
     */
    public synchronized long nextId() {
        long timestamp = timeGen();

        //如果當前時間小於上一次ID生成的時間戳，說明系統時鐘回退過這個時候應當丟擲異常
        if (timestamp < lastTimestamp) {
            throw new RuntimeException(
                    String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }

        //如果是同一時間生成的，則進行毫秒內序列
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            //毫秒內序列溢位
            if (sequence == 0) {
                //阻塞到下一個毫秒,獲得新的時間戳
                timestamp = tilNextMillis(lastTimestamp);
            }
        }
        //時間戳改變，毫秒內序列重置
        else {
            sequence = 0L;
        }

        //上次生成ID的時間截
        lastTimestamp = timestamp;

        //移位並通過或運算拼到一起組成64位的ID
        return ((timestamp - twepoch) << timestampLeftShift) //
                | (datacenterId << datacenterIdShift) //
                | (workerId << workerIdShift) //
                | sequence;
    }

    /**
     * 阻塞到下一個毫秒，直到獲得新的時間戳
     * @param lastTimestamp 上次生成ID的時間戳
     * @return 當前時間戳
     */
    protected long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    /**
     * 返回以毫秒為單位的當前時間
     * @return 當前時間(毫秒)
     */
    protected long timeGen() {
        return System.currentTimeMillis();
    }

5、Redis Incr 命令

Redis Incr 命令會將 key 中儲存的數字值增一。如果 key 不存在，那麼 key 的值會先被初始化為 0 ，然後再執行 INCR 操作。

這裡以jedis為例提供兩種自增ID的生成方式

第一種方式直接通過Incr命令獲取自增ID

JedisUtils.incr("inc-test1")

第二張方式獲取帶有時間戳的唯一編碼，時間細度為分鐘

    /**
     * 基於Redis生成 時間+遞增ID 的唯一編碼
     * @param key
     * @return
     */
    public static String getRedisTimeSeq(String key) {
        
        String time = DateUtils.parseDateToStr("yyyyMMddHHmm",new Date());
        
        StringBuilder sBuilder = new StringBuilder(time);
    
        sBuilder.append(JedisUtils.incr(key+":"+time,120));//保證一分鐘內KEY有效
        
        return sBuilder.toString();
    }

二、測試

下面我們從衝突率與時間效能上，對以上幾種唯一ID的生成方式進行一個簡單的測試，同時基於併發安全的考慮，測試分為單執行緒與多執行緒兩種

    // ---------------測試---------------
    public static void main(String[] args) throws InterruptedException {
        
        int length = 10000000;
        SnowFlake snowFlake = new SnowFlake(1, 1);
        
        final CountDownLatch countDownLatch = new CountDownLatch(10);

        Map<String, String> map = new ConcurrentHashMap<String, String>();
        long begin = System.currentTimeMillis();
        for(int i=0;i<10;i++) {
            Thread thread = new Thread(new Runnable() {
                public void run() {
                    for (int i = 0; i != 1000000; ++i) {

                        String str = String.valueOf(snowFlake.nextId());
                        
//                        String str = StringUtils.getUUIDHashCode(); //根據UUID產生命令唯一標識  長度 32  字母數字組合
//                        
//                        String str = StringUtils.getOrderSeq();//根據UUID取hash值+隨機數，產生命令唯一標識 長度 16位純數字
//                        
//                        String str =StringUtils.getRandomHexString(); //長度16的16進位制字串
                                    
                        map.put(str, str);
                    

                    }
                    countDownLatch.countDown();
                    
                }
            });
            
            thread.start();
        }

        countDownLatch.await();
        
        System.out.println("衝突數為： " + (length - map.size()));
        System.out.println("sync time: " + (System.currentTimeMillis() - begin));
        
        
        Map<String, String> map1 = new ConcurrentHashMap<String, String>();
        begin = System.currentTimeMillis();
        for (int i = 0; i != length; ++i) {

            String str = String.valueOf(snowFlake.nextId());
            
//            String str = StringUtils.getUUIDHashCode();//根據UUID產生命令唯一標識
            
//            String str = StringUtils.getOrderSeq();//根據UUID取hash值+隨機數，產生命令唯一標識
            
//            String str =StringUtils.getRandomHexString();
            
            map1.put(str, str);

        }
        System.out.println("衝突數為： " + (length - map1.size()));
        System.out.println("sync time: " + (System.currentTimeMillis() - begin));
    }

 

測試結果如下：

生成方式 生成總數 併發 衝突數   耗時 
UUID產生命令唯一標識
 1000W 單執行緒 0  26166ms 
UUID產生命令唯一標識
 1000W 多執行緒 0  27915ms 
根據UUID取hash值+隨機數，產生命令唯一標識
 1000W 單執行緒  0  25405ms 
根據UUID取hash值+隨機數，產生命令唯一標識
 1000W  多執行緒  0  25023ms 
十六位隨機的十六進位制字串
 1000W   單執行緒    0   25723ms 
十六位隨機的十六進位制字串
 		 1000W    多執行緒   0  28094ms 
雪花演算法
 1000W    單執行緒  0 10100ms 
雪花演算法
 1000W   多執行緒  0 11713ms

針對 Redis Incr 命令進行了本地和區域網兩種測試， 由於千萬級資料耗時太長，資料量改為了百萬級，結果如下：

生成方式 網路環境 生成總數 併發 衝突數 耗時
Redis Incr命令獲取自增ID  本地  100W  單執行緒   0    72445ms
Redis Incr命令獲取自增ID  本地  100W  多執行緒   0    47879ms 
Redis Incr命令獲取自增ID 區域網  100W   單執行緒   0    71447ms
Redis Incr命令獲取自增ID 區域網  100W   多執行緒   0    45888ms  

Redis Incr命令生成 時間+遞增ID 的唯一編碼

 區域網  100W  單執行緒   0  236795ms

Redis Incr命令生成 時間+遞增ID 的唯一編碼

 區域網  100W  多執行緒   0  39281ms

可以看到Redis相比前面一些輕量級的ID生成方式，生成效率上有明顯差距，但在分散式環境下，且業務場景對全域性唯一ID的生成樣式有要求，   redis做為統一的ID生成器還是很有必要的。

由於測試受機器配置、網路頻寬等條件影響，以上得出的結果只是一個簡單的測試結果，證明這幾種唯一ID生成方式具備一定的可用性，大家如果有興趣可以進行更深入的測試與優化； 

三、總結

其實在日常開發中唯一ID的的生成方式與整體服務的架構與複雜度是密切相關的，本文從併發安全、衝突率、效能等多個方面列舉了幾種唯一ID的生成方式，相對比較簡單實用，但在更復雜的架構與業務場景下，對唯一ID生成的方式的考量就需要更加全面，如併發量、持久化、獲取方式等，都需要具體問題具體分析，這裡不再深入探討，希望本文對大家能有所幫助，其中如有不足與不正確的地方還望指出與海涵。

 

關注微信公眾號，檢視更多技術文章。

 

 
 

相關文章