實用向—總結一些唯一ID生成方式-有解無憂

在日常的專案開發中，我們經常會遇到需要生成唯一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生成的方式的考量就需要更加全面，如并發量、持久化、獲取方式等，都需要具體問題具體分析，這里不再深入探討，希望本文對大家能有所幫助，其中如有不足與不正確的地方還望指出與海涵，

關注微信公眾號，查看更多技術文章，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/135392.html

標籤：Java

上一篇：面試了一個 39 歲程式員，我有點慌……

下一篇：聽說這四個概念，很多 Java 老手都說不清

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