高并发下如何高效获取机器当前时间戳

本文介绍在高并发场景下System.currentTimeMillis()的性能问题及优化方案。通过创建单例SystemClock对象,使用后台线程定时更新时间,避免了频繁调用系统函数,显著提升效率。

高并发场景下System.currentTimeMillis()的性能问题的优化

System.currentTimeMillis()的调用比new一个普通对象要耗时的多(具体耗时高出多少我还没测试过,有人说是100倍左右)
System.currentTimeMillis()之所以慢是因为去跟系统打了一次交道
后台定时更新时钟,JVM退出时,线程自动回收


思路:使用一个单例 SystemClock对象,对象中开启一个后台线程,每隔一毫秒更新一次clock时间.

import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
 
/**
 * 高并发场景下System.currentTimeMillis()的性能问题的优化
 * 时间戳打印建议使用
 */
public class SystemClock {
 
    private static final String THREAD_NAME = "system.clock";
    private static final SystemClock MILLIS_CLOCK = new SystemClock(1);
    private final long precision;
    private final AtomicLong now;
 
    private SystemClock(long precision) {
        this.precision = precision;
        now = new AtomicLong(System.currentTimeMillis());
        scheduleClockUpdating();
    }
 
    public static SystemClock millisClock() {
        return MILLIS_CLOCK;
    }
 
    private void scheduleClockUpdating() {
        ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(runnable -> {
            Thread thread = new Thread(runnable, THREAD_NAME);
            thread.setDaemon(true);
            return thread;
        });
        scheduler.scheduleAtFixedRate(() ->
                now.set(System.currentTimeMillis()),
                precision, precision, TimeUnit.MILLISECONDS);
    }
 
    public long now() {
        return now.get();
    }
}

调用SystemClock.MILLIS_CLOCK.now(); 即可获取当前时间戳(毫秒值)

<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**:通过ZooKeeper或Redis分配唯一机器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
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值