Java高並發下生成訂單號

1、直接使用UUID

public static String getUUID() {
        String replaceUUID = UUID.randomUUID().toString().replace("-", "");
        return replaceUUID;
    }

2、使用UUID+時間戳

 /**
     * UUID+時間戳
     *
     * @return
     */
    public static String getUUID() {
        String replaceUUID = UUID.randomUUID().toString().replace("-", "");
        String currentTimeMillis = String.valueOf(System.currentTimeMillis());
        return replaceUUID + currentTimeMillis;
    }

但由於生成的數據沒有規律性，並且太長；

測試：

 循環1000w次

 測試代碼：

    public static void main(String[] args) {
        long startTime = System.currentTimeMillis();
        Set set=new HashSet<>();
        for(int i=0;i<10000000;i++){
            String uuid = getUUID();
            System.out.println("uuid---"+i+"======="+uuid);
            set.add(uuid);
        }
        long endTime = System.currentTimeMillis();
        System.out.println("set.size():"+set.size());
        System.out.println("endTime-startTime:"+(endTime-startTime));
    }

控制台提示：

方案一：直接使用uuid，無重復，且控制台並無報錯

 

 

 方案二：使用uuid+時間戳，超出了GC開銷限制，控制台報錯

 

 

 

3、用時間（精確到毫秒）+隨機數

         //時間（精確到毫秒）
        DateTimeFormatter ofPattern = DateTimeFormatter.ofPattern("yyyyMMddHHmmssSSS");
        String localDate = LocalDateTime.now().format(ofPattern);
        //隨機數
        String randomNumeric = RandomStringUtils.randomNumeric(8);

for循環1000w次，發現重復數據太多。因此光靠隨機數並不可靠。

4、使用 時間（精確到毫秒）+隨機數+用戶id

   /**
     * 生成訂單號（25位）：時間（精確到毫秒）+3位隨機數+5位用戶id
     */
    public static String getOrderNum(Long userId) {
        //時間（精確到毫秒）
        DateTimeFormatter ofPattern = DateTimeFormatter.ofPattern("yyyyMMddHHmmssSSS");
        String localDate = LocalDateTime.now().format(ofPattern);
        //3位隨機數
        String randomNumeric = RandomStringUtils.randomNumeric(3);
        //5位用戶id
        int subStrLength = 5;
        String sUserId = userId.toString();
        int length = sUserId.length();
        String str;
        if (length >= subStrLength) {
            str = sUserId.substring(length - subStrLength, length);
        } else {
            str = String.format("%0" + subStrLength + "d", userId);
        }
        String orderNum = localDate + randomNumeric + str;
        log.info("訂單號:{}", orderNum);
        return orderNum;
    }

在2的基礎上改造，加入用戶的id等其他的業務id。

5.Java實現Snowflake算法的方案（高並發下，推薦使用這個）

package com.lucifer.order.util.idgenerate;
 
/**
 * Twitter_Snowflake<br>
 * SnowFlake的結構如下(每部分用-分開):<br>
 * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br>
 * 1位標識，由於long基本類型在Java中是帶符號的，最高位是符號位，正數是0，負數是1，所以id一般是正數，最高位是0<br>
 * 41位時間截(毫秒級)，注意，41位時間截不是存儲當前時間的時間截，而是存儲時間截的差值（當前時間截 - 開始時間截)
 * 得到的值），這里的的開始時間截，一般是我們的id生成器開始使用的時間，由我們程序來指定的（如下下面程序IdWorker類的startTime屬性）。41位的時間截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br>
 * 10位的數據機器位，可以部署在1024個節點，包括5位datacenterId和5位workerId<br>
 * 12位序列，毫秒內的計數，12位的計數順序號支持每個節點每毫秒(同一機器，同一時間截)產生4096個ID序號<br>
 * 加起來剛好64位，為一個Long型。<br>
 * SnowFlake的優點是，整體上按照時間自增排序，並且整個分布式系統內不會產生ID碰撞(由數據中心ID和機器ID作區分)，並且效率較高，經測試，SnowFlake每秒能夠產生26萬ID左右。
 *
 * @author Lucifer
 */
public class SnowFlake {
 
    // ==============================Fields===========================================
    /**
     * 開始時間截 (2018-07-03)
     */
 
    private final long twepoch = 1530607760000L;
 
    /**
     * 機器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;
 
    //==============================Constructors=====================================
 
    /**
     * 構造函數
     *
     * @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;
    }
 
    // ==============================Methods==========================================
 
    /**
     * 獲得下一個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();
    }
 
    //==============================Test=============================================
 
    /**
     * 測試
     */
    public static void main(String[] args) {
        long startTime = System.currentTimeMillis();
        SnowFlake idWorker = new SnowFlake(0, 0);
        Set set = new HashSet();
        for (int i = 0; i < 10000000; i++) {
            long id = idWorker.nextId();
            set.add(id);
            System.out.println("id----"+i+":"+id);
        }
        long endTime = System.currentTimeMillis();
        System.out.println("set.size():" + set.size());
        System.out.println("endTime-startTime:" + (endTime - startTime));
    }
}

也可以在雪花算法生成的id的基礎上拼接日期，不過性能有所損耗。 

 public static String timestampConversionDate(String param) {
        Instant timestamp = Instant.ofEpochMilli(new Long(param));
        System.out.println("timestamp:"+param);
        LocalDateTime localDateTime = LocalDateTime.ofInstant(timestamp, ZoneId.systemDefault());
        String format = localDateTime.format(DateTimeFormatter.ofPattern("yyyyMMdd"));
        return format;
    }

測試1：

循環1000w次，發現並無重復

 

 

測試2：（ps：其實是測試的controller中寫的不對）

利用Jmeter模擬50線程去循環發請求，發現大量重復數據。

 

 這里創建一表，表中就一個字段存放id，然后利用mybatis-plus的api插入數據庫

 

 

jmeter模擬50線程，循環永遠：

 

 

控制台頓時提示大量重復：主鍵重復

 

 

后來想明白了，為什么jmter去請求會出現大量數據，因為請求的方法不是線程安全的，獲取id是第一步，將id賦值到實體類中的屬性是第二步，插入數據庫是第三步，不是原子操作，因此會出現數據重復。這里是將方法寫在controller了，實際項目中是寫到業務層，因此需要做到業務層代碼是線程安全的。
————————————————
版權聲明：本文為CSDN博主「路西法_Lucifer」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_37495786/article/details/98479463