高并发下ID生成方案

  1. 需求

    • 生成全局唯一的ID
    • 趋近有序(例如:1 3 4 6 9 18)
  2. 解决方案(涉及到数据以MySql为例)

    • 方案一:使用原生数据库的 auto_increment 来生成全局唯一ID
      • 优点:
        • 原生数据库简单快捷
        • 保证可靠唯一性
        • 步长有序固定
      • 缺点:
        • 不能保证高可用性,数据库常见的架构:一主多从(master+slave),本问题写居多,master库挂了就玩完了
        • 扩展性差,性能依赖master库写入的性能
      • 优化方案:
        • 新增master、避免单点写入
        • 数据水平切分,保证每个库生成的ID 不重复
        • 见下图:
          这里写图片描述
        • 1库平行扩展为4个库,分摊了写入的压力
        • Mysql 这边需要自行设置auto_increment_offset 确定AUTO_INCREMENT列值的起点,也就是初始值。auto_increment_increment控制列中的值的增量值,也就是步长。
        • root@localhost[kevin]> set session auto_increment_offset=1;
        • root@localhost[kevin]> set session auto_increment_increment=4;
        • 不足之处:相对保持ID递增,不过一般项目足矣
    • 方案二:单点生成ID服务,预生成id
      • 详解:数据库里记录最后一次分配的最大id,初始为max_id=1,假如第一生成 6个ID,第一步:generate-server 先获取数据库的max-id=0,第二步:然后更新 max_id=(0+6),generate-server 拿到初始max-id和本次拉取id个数生成ID,max_id < 生成ID集合 < (max_id+N)
      • 示意图:
        这里写图片描述
      • 单点服务+shadow 服务保证高可用性
      • 批量生成ID大大降低了数据库压力,且能保证ID 相对递增
      • 每秒生成10W级的ID
    • 方案三:本地生成 ID策略,依赖算法

      • 下面讲解snowflake算法,下面提供 PHP snowflake 的扩展
      • Twitter-Snowflake算法产生的背景相当简单,为了满足Twitter每秒上万条消息的请求,每条消息都必须分配一条唯一的id,这些id还需要一些大致的顺序(方便客户端排序),并且在分布式系统中不同机器产生的id必须不同。
      • Snowflake算法核心,把时间戳,工作机器id,序列号组合在一起。
      • Snowflake算法核心
      • 除了最高位bit标记为不可用以外,其余三组bit占位均可浮动,看具体的业务需求而定。默认情况下41bit的时间戳可以支持该算法使用到2082年,10bit的工作机器id可以支持1023台机器,序列号支持1毫秒产生4095个自增序列id。下文会具体分析。
      • Snowflake – 时间戳
        这里时间戳的细度是毫秒级,具体代码如下,建议使用64位linux系统机器,因为有vdso,gettimeofday()在用户态就可以完成操作,减少了进入内核态的损耗。

        uint64_t generateStamp()
        {
            timeval tv;
            gettimeofday(&tv, 0);
            return (uint64_t)tv.tv_sec * 1000 + (uint64_t)tv.tv_usec / 1000;
        }

        默认情况下有41个bit可以供使用,那么一共有T(1llu << 41)毫秒供你使用分配,年份 = T / (3600 * 24 * 365 * 1000) = 69.7年。如果你只给时间戳分配39个bit使用,那么根据同样的算法最后年份 = 17.4年。

      • Snowflake – 工作机器id
        严格意义上来说这个bit段的使用可以是进程级,机器级的话你可以使用MAC地址来唯一标示工作机器,工作进程级可以使用IP+Path来区分工作进程。如果工作机器比较少,可以使用配置文件来设置这个id是一个不错的选择,如果机器过多配置文件的维护是一个灾难性的事情。
        这里的解决方案是需要一个工作id分配的进程,可以使用自己编写一个简单进程来记录分配id,或者利用Mysql auto_increment机制也可以达到效果。

      • snowflake - 工作id
        工作进程与工作id分配器只是在工作进程启动的时候交互一次,然后工作进程可以自行将分配的id数据落文件,下一次启动直接读取文件里的id使用。

        PS:这个工作机器id的bit段也可以进一步拆分,比如用前5个bit标记进程id,后5个bit标记线程id之类:D

      • Snowflake – 序列号
        序列号就是一系列的自增id(多线程建议使用atomic),为了处理在同一毫秒内需要给多条消息分配id,若同一毫秒把序列号用完了,则“等待至下一毫秒”。

        
        uint64_t waitNextMs(uint64_t lastStamp)
        {
            uint64_t cur = 0;
            do {
                cur = generateStamp();
            } while (cur <= lastStamp);
            return cur;
        }

        总体来说,是一个很高效很方便的GUID产生算法,一个int64_t字段就可以胜任,不像现在主流128bit的GUID算法,即使无法保证严格的id序列性,但是对于特定的业务,比如用做游戏服务器端的GUID产生会很方便。另外,在多线程的环境下,序列号使用atomic可以在代码实现上有效减少锁的密度。

<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、付费专栏及课程。

余额充值