架构分布式

技术

发布日期: 2026-03-15

文章字数: 3.7k

阅读时长: 16 分

订单号生成方案

在分布式系统中，如何生成全局唯一且有序的订单号是一个核心问题。本文将详细介绍雪花算法（Snowflake）及其在实际业务中的应用。

1. 雪花算法介绍

雪花算法（Snowflake）是 Twitter 开源的分布式 ID 生成算法，其核心思想是将一个 64 位的整数划分为多个bit位，每个bit位代表不同的含义，从而保证在分布式环境下生成唯一 ID。

1.1 雪花算法bit位分配

graph TD
    A[64位雪花ID] --> B[第1位]
    A --> C[第2-42位]
    A --> D[第43-52位]
    A --> E[第53-64位]
    
    B1[符号位
固定为0]
    C1[时间戳
41位
支持69年]
    D1[机器ID
10位
支持1024台]
    E1[序列号
12位
每毫秒4096个]
    
    B --> B1
    C --> C1
    D --> D1
    E --> E1

具体结构如下：

bit位	含义	长度	说明
第1位	符号位	1	固定为0，表示正数
第2-42位	时间戳	41	毫秒时间戳，可表示69年
第43-52位	机器ID	10	可配置，通常包含数据中心ID+机器ID
第53-64位	序列号	12	每毫秒内的自增序列，最大4096

1.2 雪花算法代码实现

package snowflake

import (
    "errors"
    "sync"
    "time"
)

const (
    // 序列号bit位数
    sequenceBits = 12
    // 机器IDbit位数
    workerIDBits = 10
    // 时间戳bit位数
    timestampBits = 41

    // 序列号最大值
    sequenceMask = (1 << sequenceBits) - 1
    // 机器ID最大值
    workerIDMask = (1 << workerIDBits) - 1

    // 机器ID左移位数
    workerIDShift = sequenceBits
    // 时间戳左移位数
    timestampShift = sequenceBits + workerIDBits
)

var (
    // 起始时间戳 2020-01-01 00:00:00
    epoch = int64(1577836800000)
)

type Snowflake struct {
    workerID     int64
    datacenterID int64
    sequence     int64
    lastTimestamp int64
    mu           sync.Mutex
}

func NewSnowflake(workerID, datacenterID int64) (*Snowflake, error) {
    if workerID < 0 || workerID > workerIDMask {
        return nil, errors.New("worker ID out of range")
    }
    if datacenterID < 0 || datacenterID > workerIDMask {
        return nil, errors.New("datacenter ID out of range")
    }

    return &Snowflake{
        workerID:     workerID,
        datacenterID: datacenterID,
        sequence:     0,
        lastTimestamp: -1,
    }, nil
}

func (s *Snowflake) NextID() (int64, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    timestamp := currentTimeMillis()

    // 时钟回拨检测
    if timestamp < s.lastTimestamp {
        return 0, errors.New("clock moved backwards")
    }

    // 同一毫秒内，序列号自增
    if timestamp == s.lastTimestamp {
        s.sequence = (s.sequence + 1) & sequenceMask
        if s.sequence == 0 {
            // 序列号用完，等待下一毫秒
            timestamp = s.waitNextMillis(timestamp)
        }
    } else {
        s.sequence = 0
    }

    s.lastTimestamp = timestamp

    // 组装ID
    id := ((timestamp - epoch) << timestampShift) |
        (s.datacenterID << workerIDShift) |
        (s.workerID << workerIDShift) |
        s.sequence

    return id, nil
}

func currentTimeMillis() int64 {
    return time.Now().UnixMilli()
}

func (s *Snowflake) waitNextMillis(lastTimestamp int64) int64 {
    timestamp := currentTimeMillis()
    for timestamp <= lastTimestamp {
        time.Sleep(time.Millisecond)
        timestamp = currentTimeMillis()
    }
    return timestamp
}

1.3 雪花算法优缺点

优点：

高性能：本地生成，不依赖数据库，单机每秒可生成约409.6万个ID
趋势递增：毫秒数在高位，序列号在低位，整体趋势递增
灵活可配置：可根据业务需求调整各bit位长度

缺点：

强依赖时钟：如果机器时钟回拨，可能导致ID重复
无法严格递增：只能保证趋势递增，不能保证严格单调递增

2. 雪花算法在实际生产环境中的应用

在实际业务中，特别是外卖等高频交易场景，我们需要保证同一用户的订单能够聚合在一起，便于查询和分析。

2.1 基于用户ID的订单分片策略

为了实现同一用户的订单聚合，我们采用对用户ID取模的方式：

package order

const (
    // 分表数量，通常设置为10000
    ShardingCount = 10000

    // 质数取模，使数据分布更均匀
    PrimeModulus = 9973
)

// GenerateOrderId 生成订单号
// snowflakeId: 雪花算法生成的ID
// buyerId: 买家ID
// 返回: 实际使用的订单号
func GenerateOrderId(snowflakeId int64, buyerId int64) string {
    // 对buyerId取模，得到4位数字
    buyerMod := int(buyerId % PrimeModulus)

    // 将雪花ID左移4位，腾出空间存放buyerId取模结果
    // 保证同一用户的订单在一起（最后4位相同）
    orderId := (snowflakeId << 4) | int64(buyerMod)

    return strconv.FormatInt(orderId, 10)
}

2.2 为何使用质数取模？

使用质数取模的主要原因：

数据分布更均匀：质数取模可以使得取模结果在0到质数-1的范围内均匀分布，避免出现热点数据问题
减少哈希冲突：质数与大多数数字的最大公约数为1，使得取模结果更加分散
打散连续ID：即使buyerId是连续的，使用质数取模后，最后4位也会均匀分布

graph LR
    A[buyerId=1] --> B[1 % 9973 = 1]
    A[buyerId=2] --> C[2 % 9973 = 2]
    A[buyerId=3] --> D[3 % 9973 = 3]
    A[buyerId=9974] --> E[9974 % 9973 = 1]
    
    B --> F[订单号末尾: ...0001]
    C --> G[订单号末尾: ...0002]
    D --> H[订单号末尾: ...0003]
    E --> I[订单号末尾: ...0001]
    
    style F fill:#90EE90
    style G fill:#90EE90
    style H fill:#90EE90
    style I fill:#90EE90

2.3 从MySQL查询优化角度解释

订单号设计的核心优势：

聚集索引优化

在MySQL InnoDB引擎中，表数据按照主键（订单号）的顺序物理存储。当同一用户的订单号末尾包含相同的取模值时，这些订单在物理存储上也是相邻的：

-- 假设 buyer_id=12345 的用户取模结果为 5678
-- 其所有订单号末尾都是 5678
SELECT * FROM orders 
WHERE order_id LIKE '%5678' 
ORDER BY order_id DESC 
LIMIT 10;

-- 由于order_id是主键（聚集索引），查询效率极高
-- 无需额外排序，物理存储即有序

覆盖索引减少回表

由于order_id包含时间信息和用户标识，可以直接通过order_id反推时间范围，减少索引使用：

-- 通过订单号可以直接确定时间范围
-- 减少对create_time索引的依赖
SELECT * FROM orders 
WHERE order_id BETWEEN '17420544000000000001' AND '17421407999999999999';

分表查询优化

-- 订单分表10000张
-- 同一用户的订单必定在同一分表
-- 无需跨表查询
SHARDING_KEY = buyer_id % 10000

3. 订单号的妙用

3.1 索引优化

在大型系统中，订单表通常数据量巨大。合理的订单号设计可以显著提升查询性能。

3.1.1 核心订单 vs 退款等附属场景

flowchart TD
    A[订单中心] --> B[核心订单表 orders]
    A --> C[退款表 refunds]
    A --> D[日志表 order_logs]
    
    B --> E[主键索引: order_id]
    B --> F[索引: buyer_id]
    B --> G[索引: store_id]
    
    C --> H[传统方案: create_time索引]
    C --> I[优化方案: order_id索引]
    
    I --> J[优势1: 索引空间更小
order_id为8字节，datetime为4字节]
    I --> K[优势2: 覆盖索引查询
可直接从order_id反推时间]
    I --> L[优势3: 范围查询更快
order_id自带排序属性]
    
    style I fill:#90EE90
    style J fill:#E0FFFF
    style K fill:#E0FFFF
    style L fill:#E0FFFF

优化示例：

-- 传统方案：使用create_time索引
SELECT * FROM refunds 
WHERE create_time >= '2026-01-01' AND create_time < '2026-01-02'
ORDER BY create_time;

-- 优化方案：使用order_id索引
-- 由于order_id包含时间信息，可以直接筛选
-- 假设2026-01-01的订单号范围是 [X, Y)
SELECT * FROM refunds 
WHERE order_id >= X AND order_id < Y
ORDER BY order_id;

3.1.2 order_id范围反推时间

由于雪花算法的高位是时间戳，我们可以通过简单的计算反推时间范围：

package order

import (
    "time"
)

const (
    // 起始时间戳 2020-01-01
    epoch = int64(1577836800000)
)

// ExtractTimestamp 从订单号中提取时间戳
func ExtractTimestamp(orderID int64) int64 {
    // 去掉末尾4位buyerId取模值和12位序列号
    return orderID >> (12 + 4)
}

// GetDayRange 获取某一天订单号的范围
func GetDayRange(year int, month int, day int) (start int64, end int64) {
    date := time.Date(year, time.Month(month), day, 0, 0, 0, 0, time.UTC)
    startTimestamp := date.UnixMilli()
    endTimestamp := startTimestamp + 86400000 // 24小时

    // 转换为订单号（简化版）
    base := (startTimestamp - epoch) << 16
    start = base
    end = (endTimestamp - epoch) << 16

    return
}

3.2 系统切换与迁移

在系统升级或迁移过程中，订单号可以作为灰度切换的标识，实现平滑过渡。

3.2.1 基于order_id的平滑迁移方案

flowchart TD
    A[订单系统迁移] --> B[定义迁移时间点T]
    A --> C[新系统最小order_id: MIN_NEW]
    A --> D[旧系统最大order_id: MAX_OLD]
    
    B --> E{order_id < MIN_NEW?}
    
    E -->|Yes| F[新逻辑处理]
    E -->|No| G[旧逻辑处理]
    
    F --> H[走新系统流程]
    G --> I[走老系统流程]
    
    J[消费者A: 退款] --> K{order_id范围判断}
    J[消费者B: 通知] --> L{order_id范围判断}
    
    K --> M[阈值: 1742000000000000000]
    L --> M
    
    M --> N[≤阈值: 新逻辑]
    M --> O[>阈值: 旧逻辑]
    
    style M fill:#FFE4B5
    style N fill:#90EE90
    style O fill:#FFB6C1

实现示例：

package migrator

// 迁移阈值，由业务方提前计算并配置
const MigrationThreshold = int64(1742000000000000000)

type LogicType string

const (
    LogicTypeNew LogicType = "NEW" // 新逻辑
    LogicTypeOld LogicType = "OLD" // 老逻辑
)

// GetLogicType 判断使用新逻辑还是老逻辑
func GetLogicType(orderID int64) LogicType {
    if orderID < MigrationThreshold {
        return LogicTypeNew
    }
    return LogicTypeOld
}

// OrderRefundEvent 退款事件
type OrderRefundEvent struct {
    OrderID   int64  `json:"order_id"`
    RefundID  string `json:"refund_id"`
    BuyerID   int64  `json:"buyer_id"`
}

// HandleRefund 退款消费者
func HandleRefund(event OrderRefundEvent) {
    logicType := GetLogicType(event.OrderID)

    switch logicType {
    case LogicTypeNew:
        // 新退款流程
        handleRefundNew(event)
    case LogicTypeOld:
        // 老退款流程
        handleRefundOld(event)
    }
}

func handleRefundNew(event OrderRefundEvent) {
    // TODO: 实现新退款流程
}

func handleRefundOld(event OrderRefundEvent) {
    // TODO: 实现老退款流程
}

3.2.2 迁移优势

无状态切换：无需重启服务，通过配置阈值实现动态切换
可回滚：如果新逻辑出现问题，只需调整阈值即可回滚
精确控制：可以精确到每个订单号维度进行切换
可观测：通过监控不同逻辑处理的订单数量，评估迁移效果

4. 其他场景的有序订单号生成

4.1 取餐号生成方案

在外卖业务中，取餐号需要满足以下特点：

单一店铺有序：每个店铺的取餐号独立递增
短号易于区分：通常为3位数，方便用户识别
循环复用：号段循环，从999回到1

4.1.1 方案一：号段模式（Leaf Segment）

原理： 每次从数据库获取一段号码，内存中逐个分配，耗尽后再去数据库获取新号段。

flowchart LR
    A[数据库] -->|1. 获取号段[1-1000]| B[Leaf服务]
    B -->|2. 分配号码| C[商家]
    C -->|3. 请求取餐号| B
    B -->|返回: 5| C
    C -->|4. 号码用尽| B
    B -->|5. 异步获取新号段[1001-2000]| A

数据库表设计：

CREATE TABLE `meal_number_segment` (
    `biz_tag` VARCHAR(128) NOT NULL COMMENT '业务标识，如store_id',
    `max_id` BIGINT(20) NOT NULL DEFAULT '1' COMMENT '当前最大号',
    `step` INT(11) NOT NULL DEFAULT '1000' COMMENT '步长',
    `update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

优点：

性能好：批量获取，减少数据库交互
稳定可靠：依赖数据库，保证不丢号

缺点：

断号问题：服务重启时可能出现断号
启动空号：服务刚启动时，号段可能未及时加载

断号示例：

sequenceDiagram
    participant S as 服务启动
    participant DB as 数据库
    
    Note over S: 服务启动，加载号段1-1000
    S->>S: 分配: 1, 2, 3, ... 11
    
    Note over S: 服务异常重启！
    
    S->>DB: 获取新号段
    DB->>S: 返回号段1001-2000
    
    Note over S: 分配: 1001, 1002, ... 1014
    Note over S: 出现断号: 12-1000

4.1.2 方案二：Redis实现

原理： 使用Redis的原子操作实现高性能、高可用的取餐号生成。

Redis Key设计：

meal:number:store:【store_id】

实现代码：

package meal

import (
    "context"
    "fmt"
    "strconv"
    "time"

    "github.com/redis/go-redis/v9"
)

const (
    MaxNumber = 999
    MinNumber = 1
)

type NumberGenerator struct {
    redis *redis.Client
}

func NewNumberGenerator(redisClient *redis.Client) *NumberGenerator {
    return &NumberGenerator{redis: redisClient}
}

// Generate 生成取餐号
func (g *NumberGenerator) Generate(ctx context.Context, storeID string) (string, error) {
    // 使用字符串拼接代替 Sprintf，避免大括号被转义
    key := "meal:number:store:" + storeID

    // 使用Redis WATCH/MULTI/EXEC事务保证原子性
    for retries := 0; retries < 3; retries++ {
        err := g.redis.Watch(ctx, func(tx *redis.Tx) error {
            // 获取当前值
            current, err := tx.Get(ctx, key).Result()
            if err != nil && err != redis.Nil {
                return err
            }

            var currentNum int
            if current == "" {
                currentNum = 0
            } else {
                currentNum, err = strconv.Atoi(current)
                if err != nil {
                    return err
                }
            }

            // 计算下一个号码
            nextNum := currentNum + 1
            if nextNum > MaxNumber {
                nextNum = MinNumber
            }

            // 开启事务
            _, err = tx.TxPipelined(ctx, func(pipe redis.Pipeliner) error {
                pipe.Set(ctx, key, strconv.Itoa(nextNum), 0)
                return nil
            })

            return err
        }, key)

        if err == nil {
            // 成功获取，生成最终取餐号
            current, _ := g.redis.Get(ctx, key).Result()
            num, _ := strconv.Atoi(current)
            if num == 0 {
                num = 1
            }
            return fmt.Sprintf("%03d", num), nil
        }

        if err == redis.TxFailedErr {
            // 事务冲突，重试
            time.Sleep(time.Millisecond * 10)
            continue
        }
        return "", err
    }

    return "", fmt.Errorf("max retries exceeded")
}

// Init 初始化号段（可选，用于首次设置）
func (g *NumberGenerator) Init(ctx context.Context, storeID string) error {
    // 使用字符串拼接代替 Sprintf，避免大括号被转义
    key := "meal:number:store:" + storeID
    return g.redis.SetNX(ctx, key, "0", 0).Err()
}

优化版本（使用Lua脚本）：

-- Lua脚本：保证原子性的取餐号生成
local key = KEYS[1]
local max = tonumber(ARGV[1])
local min = tonumber(ARGV[2])

local current = tonumber(redis.call('GET', key) or '0')
local next = current >= max and min or (current + 1)

redis.call('SET', key, tostring(next))
return next

// 使用Lua脚本的版本
var luaScript = redis.NewScript(`
local current = tonumber(redis.call('GET', KEYS[1]) or '0')
local next = current >= 999 and 1 or (current + 1)
redis.call('SET', KEYS[1], tostring(next))
return next
`)

func (g *NumberGenerator) GenerateWithLua(ctx context.Context, storeID string) (string, error) {
    // 使用字符串拼接代替 Sprintf，避免大括号被转义
    key := "meal:number:store:" + storeID

    result, err := g.redis.Eval(ctx, luaScript, []string{key}).Result()
    if err != nil {
        return "", err
    }

    num, ok := result.(int64)
    if !ok {
        return "", fmt.Errorf("invalid result type")
    }

    return fmt.Sprintf("%03d", num), nil
}

Redis方案 vs 号段方案对比：

特性	Redis方案	号段方案
断号问题	无	有（重启时）
性能	极高	高
依赖	Redis	MySQL
复杂度	低	中
持久化	依赖Redis持久化	MySQL保证

5. 时间回拨问题及解决方案

雪花算法强依赖机器时钟，如果发生时钟回拨，可能导致ID重复。下面介绍几种解决方案：

5.1 等待法

当检测到时钟回拨时，等待时间追上后再继续生成ID。

package snowflake

import (
    "errors"
    "time"
)

type SnowflakeWithWait struct {
    *Snowflake
}

func NewSnowflakeWithWait(workerID, datacenterID int64) (*SnowflakeWithWait, error) {
    sf, err := NewSnowflake(workerID, datacenterID)
    if err != nil {
        return nil, err
    }
    return &SnowflakeWithWait{Snowflake: sf}, nil
}

func (s *SnowflakeWithWait) NextID() (int64, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    timestamp := currentTimeMillis()

    if timestamp < s.lastTimestamp {
        // 等待时间追上
        offset := s.lastTimestamp - timestamp
        //fmt.Printf("Clock back: waiting %dms\n", offset)

        time.Sleep(time.Duration(offset) * time.Millisecond)

        timestamp = currentTimeMillis()
        if timestamp < s.lastTimestamp {
            return 0, errors.New("clock moved backwards")
        }
    }

    return s.generateID(timestamp)
}

func (s *SnowflakeWithWait) generateID(timestamp int64) (int64, error) {
    if timestamp == s.lastTimestamp {
        s.sequence = (s.sequence + 1) & sequenceMask
        if s.sequence == 0 {
            timestamp = s.waitNextMillis(timestamp)
        }
    } else {
        s.sequence = 0
    }

    s.lastTimestamp = timestamp

    id := ((timestamp - epoch) << timestampShift) |
        (s.datacenterID << workerIDShift) |
        (s.workerID << workerIDShift) |
        s.sequence

    return id, nil
}

5.2 拒绝法

直接拒绝服务，返回错误码，等待人工处理。

package snowflake

import (
    "errors"
    "fmt"
)

type SnowflakeWithReject struct {
    *Snowflake
}

func NewSnowflakeWithReject(workerID, datacenterID int64) (*SnowflakeWithReject, error) {
    sf, err := NewSnowflake(workerID, datacenterID)
    if err != nil {
        return nil, err
    }
    return &SnowflakeWithReject{Snowflake: sf}, nil
}

func (s *SnowflakeWithReject) NextID() (int64, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    timestamp := currentTimeMillis()

    if timestamp < s.lastTimestamp {
        return 0, fmt.Errorf(
            "clock moved backwards, refusing to generate id for %d milliseconds",
            s.lastTimestamp-timestamp,
        )
    }

    return s.generateID(timestamp)
}

5.3 序列号偏移法

利用序列号bit位的多位数，允许在一定范围内"绕回"。

package snowflake

import (
    "errors"
    "time"
)

const (
    timeoutThreshold = int64(5) // 5ms
)

type SnowflakeWithSequence struct {
    *Snowflake
}

func NewSnowflakeWithSequence(workerID, datacenterID int64) (*SnowflakeWithSequence, error) {
    sf, err := NewSnowflake(workerID, datacenterID)
    if err != nil {
        return nil, err
    }
    return &SnowflakeWithSequence{Snowflake: sf}, nil
}

func (s *SnowflakeWithSequence) NextID() (int64, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    timestamp := currentTimeMillis()

    if timestamp < s.lastTimestamp {
        offset := s.lastTimestamp - timestamp

        if offset <= timeoutThreshold {
            // 小幅度回拨，等待2倍时间
            time.Sleep(time.Duration(offset*2) * time.Millisecond)

            timestamp = currentTimeMillis()
            if timestamp < s.lastTimestamp {
                return 0, errors.New("clock still backwards")
            }
        } else {
            // 大幅度回拨，抛异常
            return 0, errors.New("large clock backwards")
        }
    }

    return s.generateID(timestamp)
}

5.4 雪花算法改进版：百度UidGenerator

百度开源的UidGenerator使用TCP协议的原子计数器来避免时钟回拨问题。

flowchart TD
    A[UidGenerator] --> B[雪花算法]
    A --> C[TCP/CAS保证序列号]
    
    B --> D[41位时间戳]
    B --> E[22位序列号]
    B --> F[1位标志位]
    
    C --> G[同一毫秒内
序列号不重复]
    C --> H[即使时间回拨
序列号仍递增]

5.5 解决方案对比

方案	优点	缺点	适用场景
等待法	保证ID不重复	服务短暂不可用	对ID连续性要求高的场景
拒绝法	实现简单	可能丢失ID	对可用性要求高的场景
序列号偏移	容忍小幅度回拨	复杂度增加	多数业务场景
百度UidGenerator	彻底解决回拨	依赖额外组件	大型分布式系统

6. 其他问题（FAQ）

Q1: 为什么要对用户ID取模而不是直接使用用户ID？

A：取模的主要目的是：

控制取模结果长度：用户ID可能是十几位数字，直接拼接会导致订单号过长
数据分布均匀：连续的user_id取模后分布更随机，避免热点
固定长度：取模后固定4位（对9973取模），便于计算和存储

Q2: 为什么要用质数取模？

A：使用质数（如9973）取模的原因：

均匀分布：质数与任意整数的最大公约数通常为1，使得取模结果在[0, 质数-1]范围内分布均匀
减少冲突：相比合数，质数能更好地打散连续ID的聚集性
哈希表优化：这是计算机科学中经典的哈希取模优化技巧

package main

import "fmt"

func main() {
    userIDs := []int{1, 2, 3, 4, 5, 100, 200, 300, 1000, 2000}

    fmt.Println("=== 使用合数10000取模 ===")
    for _, id := range userIDs {
        fmt.Printf("%d ", id%10000)
    }
    // 结果：1 2 3 4 5 100 200 300 1000 2000

    fmt.Println("\n=== 使用质数9973取模 ===")
    for _, id := range userIDs {
        fmt.Printf("%d ", id%9973)
    }
    // 结果：1 2 3 4 5 100 200 300 1000 2000

    // 但对于连续范围的user_id
    continuousIDs := []int{100, 101, 102, 103, 104, 105}
    fmt.Println("\n=== 连续ID用10000取模 ===")
    for _, id := range continuousIDs {
        fmt.Printf("%d ", id%10000)
    }
    // 结果：100 101 102 103 104 105 （仍然连续）

    fmt.Println("\n=== 连续ID用9973取模 ===")
    for _, id := range continuousIDs {
        fmt.Printf("%d ", id%9973)
    }
    // 结果：100 101 102 103 104 105 （仍然连续，因为范围小于质数）

    // 但对于大范围连续ID
    largeRange := []int{1, 2, 3, 4, 5, 9973, 9974, 9975, 9999, 10000}
    fmt.Println("\n=== 大范围连续ID用10000取模 ===")
    for _, id := range largeRange {
        fmt.Printf("%d ", id%10000)
    }
    // 结果：1 2 3 4 5 9973 9974 9975 9999 0

    fmt.Println("\n=== 大范围连续ID用9973取模 ===")
    for _, id := range largeRange {
        fmt.Printf("%d ", id%9973)
    }
    // 结果：1 2 3 4 5 0 1 2 26 27（分布更均匀）
}

Q3: 如果超过41位时间戳范围怎么办？

A： 41位时间戳可以表示约69年（从指定起始时间开始）。解决方案：

设置合理的起始时间：例如设置为2020-01-01，可以用到2089年
迁移方案：提前规划，当接近时间戳上限时进行系统迁移
扩展时间戳位：在业务允许的情况下，可以压缩其他bit位（如减少机器ID位数）来延长使用时间

package main

import (
    "fmt"
    "time"
)

func main() {
    // 雪花算法41位时间戳的起始时间通常是2020-01-01或1970-01-01
    // 假设起始时间为2020-01-01 00:00:00 UTC
    epochStart := int64(1577836800000) // 2020-01-01 00:00:00 UTC
    maxTimestamp := int64(1<<41) - 1   // 2199023255551

    maxTime := epochStart + maxTimestamp
    fmt.Printf("最大可表示时间: %v\n", time.UnixMilli(maxTime))
    // 输出：2089-09-07 15:47:35

    // 计算剩余年限
    yearsRemaining := (maxTime - time.Now().UnixMilli()) / (365 * 24 * 3600 * 1000)
    fmt.Printf("剩余可用年限: %d 年\n", yearsRemaining)
}

Q4: 为什么要把订单号转成String传给前端？

A：主要原因：

JavaScript整数精度问题：JavaScript的Number类型使用IEEE 754双精度浮点数，最大安全整数为2^53-1（约9×10^15），而64位雪花ID可能超过这个范围
避免精度丢失：超过9×10^15的整数在JavaScript中会被截断

// JavaScript精度问题示例
const orderId = 1742054400000005678;
console.log(orderId);  // 输出: 1742054400000006000（精度丢失！）

// 解决方案：使用String
const orderIdStr = "1742054400000005678";
console.log(orderIdStr);  // 输出: "1742054400000005678"（正确）