Java 生成订单号或唯一id(高并发)方案

本文探讨了多种ID生成方法,包括UUID、时间戳结合随机数、业务ID组合以及Snowflake算法。详细介绍了每种方法的特点及应用场景,特别是Snowflake算法的工作原理和实现。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1、直接使用uuid

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

但由于生成的数据没有规律性,并且太长;

测试:循环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));
    }

控制台提示:

 

2、用时间(精确到毫秒)+随机数

         //时间(精确到毫秒)
        DateTimeFormatter ofPattern = DateTimeFormatter.ofPattern("yyyyMMddHHmmssSSS");
        String localDate = LocalDateTime.now().format(ofPattern);
        //随机数
        String randomNumeric = RandomStringUtils.randomNumeric(8);

for循环1000w次,发现重复数据太多。因此光靠随机数并不可靠。

3、使用 时间(精确到毫秒)+随机数+用户id(业务id)

注意:如果是类似用户id,项目当中集成了权限框架,使用工具类获取即可,就不用传参了

   /**
     * 生成订单号(25位):时间(精确到毫秒)+3位随机数+5位用户id
     */
    public static synchronized  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。

4.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:100个线程,每个线程负责生成10w个id

//多线程测试
public static void main(String[] args) throws InterruptedException {
        long startTime = System.currentTimeMillis();
        CountDownLatch countDownLatch=new CountDownLatch(10000000);
        final SnowFlake idWorker = new SnowFlake(0, 0);
        Set set = Collections.synchronizedSet(new HashSet());
        for (int i = 0; i < 100; i++) {
            Thread thread = new Thread(() -> {
                for (int i1 = 0; i1 < 100000; i1++) {
                    long id = idWorker.nextId();
                    System.out.println("id:"+id);
                    set.add(id);
                    countDownLatch.countDown();
                }
            });
            thread.start();
        }
        countDownLatch.await();
        long endTime = System.currentTimeMillis();
        System.out.println("set.size():" + set.size());
        System.out.println("endTime-startTime:" + (endTime - startTime));
    }

 

<think>我们正在讨论高并发场景下生成唯一订单ID的最佳方案。根据引用[1]和[4],我们知道订单号需要满足全局唯一性、趋势递增、高可读性以及高性能。同时,引用[2]和[3]提到了在分布式系统中如何保证唯一性以及Snowflake算法。 结合这些信息,我们可以考虑以下几种方案: 1. Redis INCR方案:利用Redis的原子递增操作生成唯一ID,适合高并发,但需要保证Redis的高可用。 2. Snowflake算法:分布式自增ID算法,通过时间戳、工作机器ID和序列号组合生成ID,不依赖中间件。 3. 结合时间戳和机器信息的自定义方案:如引用[2]所述,将时间戳、机器标识(如IP、进程ID、线程ID)和序列号组合。 其中,最佳实践通常需要根据具体场景选择: - 如果系统已经使用Redis,并且Redis集群稳定,那么Redis INCR方案简单高效,且天然具有递增性。 - 如果系统需要去中心化,避免单点故障,Snowflake算法是更好的选择,但需要注意机器ID的分配和时钟回拨问题。 下面我们详细描述这两种方案,并给出示例代码(Java)。 ### 方案一:基于Redis INCR的订单号生成 原理:利用Redis的原子性INCR命令生成递增的序列号。为了满足可读性,我们可以在序列号前加上时间戳和机器标识。 步骤: 1. 生成基础序列号:使用Redis的INCR命令获取一个全局递增的整数。 2. 拼接订单号订单号 = 时间戳(精确到毫秒秒) + 机器标识(如机器IP的哈希值取后几位) + 业务标识 + 序列号。 示例订单号格式:`20240530143600123`(时间戳部分为2024-05-30 14:36:00,后面接123这个序列号)。但为了区分不同机器,我们可以在中间加入机器标识。 优化:为了避免每次生成ID都访问Redis,可以采用批量获取的方式(即一次性获取一个号段,然后在本地内存中分配)。 Java示例代码(使用RedisTemplate): ```java import org.springframework.data.redis.core.RedisTemplate; public class RedisOrderIdGenerator { private RedisTemplate<String, String> redisTemplate; private String machineId; // 机器标识,可以从配置中获取,者用IP的后几位 public RedisOrderIdGenerator(RedisTemplate<String, String> redisTemplate, String machineId) { this.redisTemplate = redisTemplate; this.machineId = machineId; } public String generateOrderId() { // 获取当前时间戳(精确到秒) String timestamp = String.valueOf(System.currentTimeMillis() / 1000); // 使用INCR获取序列号,key可以包含时间戳(按天按小时)以避免序列号过长 String key = "orderId:" + timestamp; Long sequence = redisTemplate.opsForValue().increment(key, 1); // 如果key是新的,设置过期时间,比如1天 if (sequence != null && sequence == 1) { redisTemplate.expire(key, 1, TimeUnit.DAYS); } // 拼接订单号:时间戳+机器标识+序列号 return timestamp + machineId + sequence; } } ``` 注意:此方案中,同一个时间戳(秒级)内,序列号是递增的。机器标识用来区分不同机器,防止不同机器在同一秒内生成的序列号冲突。但需要确保机器标识唯一。 ### 方案二:Snowflake算法 Snowflake算法生成的是一个64位的long型ID,结构如下: - 1位符号位(始终为0) - 41位时间戳(毫秒级,可用69年) - 10位机器ID(可以配置,通常由数据中心ID和机器ID组成,各5位) - 12位序列号(每毫秒可以生成4096个ID) 优点:不依赖外部存储,性能高。 缺点:需要配置机器ID,且时钟回拨问题需要处理。 Java示例代码(简化版,未处理时钟回拨): ```java public class SnowflakeIdGenerator { private final long machineId; // 机器ID(0~31) private final long dataCenterId; // 数据中心ID(0~31) private long sequence = 0L; private long lastTimestamp = -1L; public SnowflakeIdGenerator(long machineId, long dataCenterId) { this.machineId = machineId; this.dataCenterId = dataCenterId; } public synchronized long nextId() { long currentTimestamp = System.currentTimeMillis(); if (currentTimestamp < lastTimestamp) { throw new RuntimeException("时钟回拨异常"); } if (currentTimestamp == lastTimestamp) { sequence = (sequence + 1) & 4095; // 12位序列号,最大4095 if (sequence == 0) { // 当前毫秒的序列号用尽,等待下一毫秒 currentTimestamp = waitNextMillis(currentTimestamp); } } else { sequence = 0; } lastTimestamp = currentTimestamp; return ((currentTimestamp) << 22) | (dataCenterId << 17) | (machineId << 12) | sequence; } private long waitNextMillis(long currentTimestamp) { long now = System.currentTimeMillis(); while (now <= currentTimestamp) { now = System.currentTimeMillis(); } return now; } } ``` 使用上述类生成ID,然后可以转换为字符串作为订单号。注意,机器ID和数据中心ID需要确保在分布式环境中唯一。 ### 方案对比与最佳实践建议 - **Redis INCR方案**: - 优点:简单,易于实现,生成订单号可读性好(可以包含时间信息),且能保证严格递增。 - 缺点:依赖Redis,需要保证Redis的高可用(集群主从+哨兵),网络调用有一定延迟(批量获取可以缓解)。 - **Snowflake方案**: - 优点:性能极高,不依赖外部服务,去中心化。 - 缺点:需要解决机器ID分配问题,时钟回拨问题需要处理(如使用开源的改进版算法,如百度UidGenerator、美团Leaf等)。 根据引用[1]中提到的工业级实践,可以结合两种方案的优势: 1. 对于订单号的可读性要求高,且系统已经使用Redis,可以选择Redis方案,并采用批量获取号段的方式(例如每次从Redis获取1000个号段,在本地内存中分配,减少Redis访问次数)。 2. 对于系统可用性要求极高(不能容忍Redis故障),且订单号不需要严格递增(趋势递增即可),可以选择Snowflake算法。 ### 高并发下的优化 - **Redis方案优化**:使用号段模式(即每次从Redis获取一个区间,例如当前值增加1000,然后本地从该区间内分配,区间用完后再次申请),这样可以大大减少对Redis的访问次数,提高性能。 - **Snowflake优化**:使用缓冲队列预生成ID,避免在生成时同步等待。 ### 总结 在高并发场景下,生成唯一订单号的最佳方案需要根据系统架构和需求选择: - 如果系统有Redis且运维能力较强,推荐使用Redis的号段模式(预分配)生成订单号,兼顾性能和可读性。 - 如果系统追求去中心化和高性能,且能解决机器ID分配问题,推荐使用Snowflake算法其改进版本。 无论选择哪种方案,都需要确保全局唯一性,并在高并发压力下进行充分测试[^1][^4]。 §§相关问题§§ 1. Redis号段模式生成订单号的具体实现步骤是什么? 2. 如何解决Snowflake算法中的时钟回拨问题? 3. 在分布式系统中,如何保证机器ID唯一性?</think>### 高并发场景下生成唯一订单ID的最佳方案高并发场景中生成唯一订单ID需满足四个核心要求:**全局唯一性**、**趋势递增性**、**高可读性**和**高性能**(支持万级QPS)[^1]。以下是经过工业验证的三种最佳方案: --- #### 方案一:Redis INCR + 分段预生成(推荐) **原理**:结合Redis原子性和本地缓存,通过预生成ID段减少网络开销 ```mermaid graph LR A[客户端] --> B{ID池是否为空?} B -- 是 --> C[Redis批量获取ID段] C --> D[存储到本地ID池] B -- 否 --> E[从本地ID池分配ID] E --> F[生成完整订单号] ``` **实现步骤**: 1. **Redis预生成**:使用`INCRBY`批量获取ID段(如每次1000个) ```java // Redis操作:一次性获取1000个ID Long rangeEnd = redisTemplate.opsForValue().increment("order:id", 1000); Long rangeStart = rangeEnd - 999; ``` 2. **本地缓存**:将ID段存储在本地内存队列(如ConcurrentLinkedQueue) 3. **订单号组装**:当需要ID时从本地队列取出,拼接业务标识 ```java // 格式:业务类型+时间戳+机器ID+序列号 public String generateOrderId() { Long baseId = localIdQueue.poll(); // 从本地池获取 return "DD" + System.currentTimeMillis() + "M01" + baseId; } ``` 4. **异常处理**:本地池耗尽时自动触发Redis重新获取 **优势**: - 网络开销降低99%(单次Redis交互支持1000次ID生成)[^4] - 满足10万+ QPS要求 - 天然趋势递增,利于数据库索引优化[^1] --- #### 方案二:Snowflake算法改进版 **原理**:分布式ID生成算法,组合时间戳+机器ID+序列号 ```mermaid pie title ID结构组成 “时间戳(41位)” : 41 “机器ID(10位)” : 10 “序列号(12位)” : 12 ``` **核心改进点**: 1. **动态机器ID**:通过ZooKeeperRedis分配唯一机器ID ```java // 从Redis获取机器ID String machineId = redis.get("cluster_machine_01"); ``` 2. **时钟回拨解决**:增加时钟偏移检测,异常时采用备用时间源 3. **业务标识嵌入**:在64位ID前添加业务前缀 ```java // 生成示例:DD-2024053014360012345 public String generate() { long id = snowflake.nextId(); return "DD-" + DateTimeFormatter.format("yyyyMMddHHmmss") + id; } ``` **适用场景**:无Redis依赖的纯分布式系统[^3] --- #### 方案三:多维度复合编码 **原理**:组合机器标识+时间戳+原子序列,无需中央存储[^2] ```java // 格式:IP末段+进程ID+线程ID+时间戳+序列号 public String generate() { String ip = getLastIPSegment(); // 如192.168.1.1 -> "1011" String pid = String.format("%04d", getProcessId()); String tid = String.format("%04d", Thread.currentThread().getId()); String timestamp = String.valueOf(System.currentTimeMillis()); String seq = String.format("%04d", atomicCounter.incrementAndGet()); return ip + pid + tid + timestamp.substring(5) + seq; } ``` **优势**: - 完全去中心化,无单点故障 - 通过IP/进程/线程ID保证跨机器唯一性[^2] - 时间戳精度到毫秒级防碰撞 --- ### 方案选型建议 | 场景 | 推荐方案 | QPS上限 | 缺点 | |-----------------------|------------------|------------|--------------------| | Redis可用环境 | INCR+预生成池 | 50万+ | 依赖Redis可用性 | | 纯分布式架构 | Snowflake改进版 | 100万+ | 需解决时钟回拨 | | 无基础设施依赖 | 多维度复合编码 | 10万+ | ID较长(40位左右) | > **最佳实践**:电商系统推荐采用**Redis预生成方案**,通过以下优化进一步提升性能: > 1. 双缓冲ID池:交替加载ID段,避免分配等待 > 2. 时间戳压缩:使用Base36编码将毫秒时间戳从13位压缩到8位 > 3. 机器标识复用:对IP/机器ID进行哈希映射生成2字节短编码[^1] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

吴名氏.

你的鼓励是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值