批量创建：运营的"核武器"

📅 2026-02-28 📁 礼包码篇 ⏱️ 7 分钟

这是"游戏礼包码系统"系列文章的第三篇。前两篇我们聊了礼包码的历史和生成算法，今天来聊聊运营最关心的能力——批量创建。

引言

"小王，明天的周年庆活动需要准备 500 万个礼包码，分 50 个渠道发放，今晚必须上线。"

这种场景在游戏运营中并不少见。每逢大促、节日、版本更新，批量创建礼包码都是"常规操作"。而支撑这些操作的，就是一套稳定、高效的批量创建系统。

今天，我们就来聊聊这个运营的"核武器"——批量创建系统背后的设计思路。

一、为什么需要批量创建？

1.1 运营场景的规模化需求

单个礼包码可以直接在后台手动创建。但当运营需求规模化时，手动方式就力不从心了。

游戏上线时，可能同时接入 20 个应用商店、30 个媒体渠道、50 个 KOL。每个渠道都需要专属礼包码，用于追踪效果。这些码需要在短时间内生成、分发、上线。

春节、周年庆、版本大更新，这些节点往往需要大规模发放福利。动辄百万级的码量，必须在活动开始前全部准备就绪。

基于用户画像的精准投放，每个用户收到的码都是唯一的。这种"千人千码"的场景，只能依靠批量生成。

1.2 手动创建的局限性

维度	手动创建	批量创建
数量	每次几个	每次百万级
时间	分钟级	秒级到分钟级
错误率	人为失误多	系统化保障
可追溯	靠人工记录	系统自动记录

批量创建不只是"多做几次"，而是从流程到技术的全方位升级。

二、批量创建的技术挑战

2.1 性能挑战

假设生成一个码需要 1 毫秒，生成 1 亿个需要约 27 小时。活动早就结束了。

2.2 一致性挑战

批量创建不只是"生成"，还涉及：

配置的一致性： 100 万个码的礼包内容必须完全一致
计数的一致性： 限量 100 万就是 100 万，不能多也不能少
状态的一致性： 生成完成时，所有码的状态必须同步

典型问题：生成到一半服务器宕机，已生成的码怎么办？多台服务器并行生成，如何保证序号不冲突？

2.3 可追溯挑战

批量生成的码不是"生完就完"，还需要：

追踪发放情况：哪些码发给了哪个渠道？
追踪使用情况：使用率多少？
追溯问题来源：发现异常时，能定位到具体批次

三、批量创建的核心算法原理

这一节，我们深入探讨批量生成背后的算法设计。如果把礼包码生成比作"印钞"，那批量生成就是"印钞厂的流水线"——需要高效、准确、可控。

3.1 并发生成的核心问题：序号冲突

想象一下，四个窗口同时卖票，如果每个窗口都从 1 开始编号，那就会出现四张"1号票"。解决这个问题有几种经典方案：

方案一：中央序号服务（集中式）

┌─────────────┐
│ 序号服务    │ ← 全局唯一序号源
│ (单点)      │
└──────┬──────┘
       │ 分配序号
   ┌───┴───┬───────┬───────┐
   ▼       ▼       ▼       ▼
生成器A  生成器B  生成器C  生成器D

每次生成前，先向中央服务申请一个序号。简单直接，但问题是——中央服务成为瓶颈。假设每秒只能处理 1 万次请求，那整个系统的上限就被锁死了。

方案二：序号段预分配（分布式）

这是业界主流方案。核心思想是：一次申请一批，本地慢慢用。

┌─────────────┐
│ 序号服务    │
└──────┬──────┘
       │ 预分配序号段
   ┌───┴───────────────────┐
   │                       │
   ▼                       ▼
┌──────────┐         ┌──────────┐
│ 生成器A  │         │ 生成器B  │
│ [1-100万]│         │[100万-200万]
└──────────┘         └──────────┘

type SequenceAllocator struct {
    current int64  // 当前已分配到的位置
    step    int64  // 每次预分配的步长
}

// 预分配一个序号段
func (s *SequenceAllocator) AllocateSegment() (start, end int64) {
    start = atomic.AddInt64(&s.current, s.step) - s.step
    end = start + s.step - 1
    return start, end
}

// 本地生成器
type LocalGenerator struct {
    segmentStart int64
    segmentEnd   int64
    currentPos   int64
    mu           sync.Mutex
}

func (g *LocalGenerator) Next() (int64, error) {
    g.mu.Lock()
    defer g.mu.Unlock()
    
    if g.currentPos > g.segmentEnd {
        // 本地段用完，需要重新申请
        return 0, errors.New("segment exhausted")
    }
    
    g.currentPos++
    return g.currentPos, nil
}

中央服务压力降低 1000 倍（假设步长为 100 万）
各生成器完全并行，互不干扰
网络开销从 N 次变成 1 次

如果生成器挂了，预分配的序号段可能浪费
需要合理设置步长（太大浪费，太小频繁申请）

3.2 批量生成算法详解

3.2.1 雪花算法（Snowflake）的批量应用

雪花算法生成的 ID 包含：时间戳 + 机器ID + 序列号。在批量场景下，我们可以利用其特性：

┌─────────────────────────────────────────────────────────────┐
│                    64位 Snowflake ID                        │
├──────────────┬─────────────┬────────────────────────────────┤
│  时间戳(41位) │ 机器ID(10位) │        序列号(12位)            │
│              │             │   (单毫秒可生成4096个)          │
└──────────────┴─────────────┴────────────────────────────────┘

type SnowflakeBatchGenerator struct {
    workerID    int64
    lastTS      int64
    sequence    int64
    maxSequence int64 = 4095  // 2^12 - 1
}

// 批量生成当前毫秒的所有ID
func (g *SnowflakeBatchGenerator) GenerateBatch() ([]int64, error) {
    g.mu.Lock()
    defer g.mu.Unlock()
    
    now := time.Now().UnixMilli()
    
    if now == g.lastTS {
        // 同一毫秒内，如果序列号已用完，等待下一毫秒
        if g.sequence >= g.maxSequence {
            time.Sleep(time.Millisecond)
            now = time.Now().UnixMilli()
            g.sequence = 0
        }
    } else {
        g.sequence = 0
        g.lastTS = now
    }
    
    // 批量生成剩余可用ID
    var ids []int64
    for g.sequence <= g.maxSequence {
        id := (now << 22) | (g.workerID << 12) | g.sequence
        ids = append(ids, id)
        g.sequence++
    }
    
    return ids, nil
}

3.2.2 并发生成的协调机制

当多个节点同时生成时，需要协调机制避免冲突：

func GenerateWithLock(nodeID string, count int) ([]string, error) {
    // 获取分布式锁
    lockKey := "giftcode:gen:lock"
    lock := redis.Lock(lockKey, 10*time.Second)
    defer lock.Release()
    
    if !lock.Acquired() {
        return nil, errors.New("lock acquisition failed")
    }
    
    // 临界区：生成礼包码
    codes := make([]string, count)
    for i := 0; i < count; i++ {
        codes[i] = generateSingleCode()
    }
    
    return codes, nil
}

type ShardingManager struct {
    nodes      []string  // 节点列表
    virtualNodes int     // 虚拟节点数
}

// 根据任务ID分配到具体节点
func (m *ShardingManager) AssignNode(taskID string) string {
    hash := crc32.ChecksumIEEE([]byte(taskID))
    index := hash % uint32(len(m.nodes) * m.virtualNodes)
    return m.nodes[index % len(m.nodes)]
}

// 批量任务分配
func (m *ShardingManager) DistributeTasks(totalCount int, batchSize int) map[string][]Task {
    assignments := make(map[string][]Task)
    
    for i := 0; i < totalCount; i += batchSize {
        taskID := fmt.Sprintf("batch_%d", i)
        node := m.AssignNode(taskID)
        task := Task{
            StartIndex: i,
            Count:      min(batchSize, totalCount - i),
        }
        assignments[node] = append(assignments[node], task)
    }
    
    return assignments
}

3.3 分布式批量生成架构

对于超大规模（千万级以上）的生成需求，单机已经不够用了。我们需要一个分布式生成系统：

                    ┌─────────────────┐
                    │   任务调度器     │
                    │ (Task Scheduler) │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
       ┌────────────┐ ┌────────────┐ ┌────────────┐
       │  Worker 1  │ │  Worker 2  │ │  Worker N  │
       │ (生成节点)  │ │ (生成节点)  │ │ (生成节点)  │
       └─────┬──────┘ └─────┬──────┘ └─────┬──────┘
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                    ┌─────────────────┐
                    │   消息队列       │
                    │ (Result Queue)  │
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    ▼                 ▼
             ┌────────────┐    ┌────────────┐
             │  存储服务   │    │  状态服务   │
             └────────────┘    └────────────┘

任务提交： 运营提交批量生成请求（如 1000 万个码）
任务拆分： 调度器将大任务拆分成小批次（如每批 10 万个）
任务分发： 通过消息队列将批次任务分发给各个 Worker
并发生成： 各 Worker 独立生成，互不干扰
结果聚合： 生成完成后，结果写入统一存储
状态同步： 实时更新任务进度，供运营查看

type BatchTaskScheduler struct {
    taskQueue    *redis.Queue
    resultQueue  *redis.Queue
    workers      []WorkerClient
    batchSize    int
}

func (s *BatchTaskScheduler) SubmitTask(req *BatchRequest) (string, error) {
    taskID := generateTaskID()
    
    // 计算需要多少个批次
    batchCount := (req.TotalCount + s.batchSize - 1) / s.batchSize
    
    // 创建批次任务
    for i := 0; i < batchCount; i++ {
        batch := &BatchTask{
            TaskID:     taskID,
            BatchIndex: i,
            StartSeq:   int64(i * s.batchSize),
            Count:      min(s.batchSize, req.TotalCount - i*s.batchSize),
            Config:     req.Config,
            CreatedAt:  time.Now(),
        }
        
        // 推送到任务队列
        s.taskQueue.Push(batch)
    }
    
    // 启动状态追踪
    go s.trackProgress(taskID, batchCount)
    
    return taskID, nil
}

func (s *BatchTaskScheduler) trackProgress(taskID string, totalBatches int) {
    completed := 0
    for completed < totalBatches {
        result := s.resultQueue.Pop()
        if result.TaskID == taskID {
            completed++
            // 更新进度
            updateProgress(taskID, completed, totalBatches)
        }
    }
    // 标记完成
    markTaskComplete(taskID)
}

四、大规模生成的性能优化实战

理论上说得再好，不如实际跑一下。这一节，我们分享一些真实场景中的性能优化经验。

4.1 数据库写入优化

for _, code := range codes {
    db.Exec("INSERT INTO gift_codes (code, batch_id, ...) VALUES (?, ?, ...)", 
            code, batchID)
}

// 每 1000 条一批
for i := 0; i < len(codes); i += 1000 {
    end := min(i+1000, len(codes))
    batch := codes[i:end]
    
    // 构建批量插入 SQL
    values := make([]string, len(batch))
    args := make([]interface{}, 0, len(batch)*5)
    for j, code := range batch {
        values[j] = "(?, ?, ?, ?, ?)"
        args = append(args, code, batchID, configID, status, createdAt)
    }
    
    sql := fmt.Sprintf("INSERT INTO gift_codes VALUES %s", 
                       strings.Join(values, ","))
    db.Exec(sql, args...)
}

对于超大规模（百万级以上），直接使用 MySQL 的批量导入功能：

// 生成 CSV 文件
file, _ := os.CreateTemp("", "giftcodes_*.csv")
for _, code := range codes {
    file.WriteString(fmt.Sprintf("%s,%d,%d,%d\n", 
                       code, batchID, configID, status))
}
file.Close()

// 使用 LOAD DATA 导入
db.Exec(`LOAD DATA LOCAL INFILE ? INTO TABLE gift_codes 
         FIELDS TERMINATED BY ',' 
         (code, batch_id, config_id, status)`, file.Name())

当单表数据量过大时，按批次 ID Hash 分表：

func getTableName(batchID int64) string {
    shard := batchID % 16  // 分 16 张表
    return fmt.Sprintf("gift_codes_%02d", shard)
}

// 并行写入
var wg sync.WaitGroup
for i := 0; i < 16; i++ {
    wg.Add(1)
    go func(shard int) {
        defer wg.Done()
        // 写入对应的分表
        writeCodesToTable(shard, codesForShard)
    }(i)
}
wg.Wait()

4.2 内存优化

func GenerateAndWrite(config *Config, count int, writer io.Writer) error {
    // 每次只生成 1 万个，处理完再生成下一批
    batchSize := 10000
    
    for i := 0; i < count; i += batchSize {
        // 生成一批
        codes := generateCodes(config, min(batchSize, count-i))
        
        // 直接写入，不保留在内存
        for _, code := range codes {
            fmt.Fprintln(writer, code)
        }
        
        // 释放内存
        codes = nil
        runtime.GC()
    }
    
    return nil
}

4.3 并行度调优

最优并行度 = CPU核心数 × (1 + I/O等待时间/CPU计算时间)

对于礼包码生成（计算密集 + 数据库 I/O）：

CPU 计算：生成码（纯计算，很快）
I/O 等待：数据库写入（较慢）

假设比例 1:10，则最优并行度 ≈ CPU核心数 × 11

func parallelGenerate(count int, workers int) {
    taskChan := make(chan int, workers*2)
    resultChan := make(chan []string, workers)
    
    // 启动 Worker
    var wg sync.WaitGroup
    for i := 0; i < workers; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for range taskChan {
                codes := generateBatch(1000)
                resultChan <- codes
            }
        }()
    }
    
    // 分发任务
    go func() {
        for i := 0; i < count; i += 1000 {
            taskChan <- i
        }
        close(taskChan)
    }()
    
    // 收集结果
    go func() {
        wg.Wait()
        close(resultChan)
    }()
    
    // 处理结果
    for codes := range resultChan {
        saveCodes(codes)
    }
}

五、批次管理与查询优化

生成完不是结束，而是运营工作的开始。如何高效管理海量批次、快速查询状态？

5.1 批次元数据设计

每个批次需要记录完整的元信息：

CREATE TABLE gift_code_batches (
    batch_id       BIGINT PRIMARY KEY,
    batch_name     VARCHAR(255),
    campaign_id    BIGINT,           -- 所属活动
    channel_id     BIGINT,           -- 分发渠道
    config_id      BIGINT,           -- 礼包配置
    total_count    INT,              -- 总数量
    used_count     INT DEFAULT 0,    -- 已使用数量
    expired_count  INT DEFAULT 0,    -- 已过期数量
    status         TINYINT,          -- 状态：创建中/正常/已作废
    valid_from     DATETIME,         -- 生效时间
    valid_until    DATETIME,         -- 失效时间
    created_by     VARCHAR(64),      -- 创建人
    created_at     DATETIME,
    completed_at   DATETIME,         -- 生成完成时间
    
    INDEX idx_campaign (campaign_id),
    INDEX idx_channel (channel_id),
    INDEX idx_status_time (status, valid_until)
);

5.2 查询优化策略

-- 慢查询（全表扫描）
SELECT channel_id, 
       COUNT(*) as total,
       SUM(CASE WHEN used_at IS NOT NULL THEN 1 ELSE 0 END) as used
FROM gift_codes
GROUP BY channel_id;

-- 优化方案：预聚合表
CREATE TABLE batch_stats (
    batch_id    BIGINT PRIMARY KEY,
    channel_id  BIGINT,
    total_count INT,
    used_count  INT,
    updated_at  DATETIME
);

-- 定时更新
UPDATE batch_stats bs
SET used_count = (
    SELECT COUNT(*) FROM gift_codes gc
    WHERE gc.batch_id = bs.batch_id AND gc.used_at IS NOT NULL
);

-- 原始方案：全表扫描
SELECT * FROM gift_codes WHERE code = 'ABCD1234';

-- 优化方案：建立索引
CREATE INDEX idx_code ON gift_codes(code);

-- 更优方案：利用码格式做分表
-- 码格式：{批次Hash(2位)}{随机字符}
-- 直接根据码前缀定位到分表
func getTableByCode(code string) string {
    prefix := code[:2]
    hash, _ := strconv.ParseInt(prefix, 16, 64)
    return fmt.Sprintf("gift_codes_%02d", hash%16)
}

5.3 批次操作优化

-- 慢操作：逐条更新
UPDATE gift_codes SET status = 2 WHERE batch_id = 123;

-- 优化一：分批更新（避免长事务）
UPDATE gift_codes SET status = 2 
WHERE batch_id = 123 AND id >= 0 AND id < 1000000;
UPDATE gift_codes SET status = 2 
WHERE batch_id = 123 AND id >= 1000000 AND id < 2000000;
-- ...

-- 优化二：异步更新
-- 1. 在批次表标记为"作废中"
UPDATE gift_code_batches SET status = 3 WHERE batch_id = 123;

-- 2. 后台任务异步更新码表
-- 3. 完成后更新批次状态为"已作废"

六、运营工具设计实战

技术再牛，运营同事用不好也是白搭。好的运营工具应该"让复杂的技术对使用者透明"。

6.1 界面设计原则

┌─────────────────────────────────────────┐
│         批量创建礼包码                    │
├─────────────────────────────────────────┤
│  *活动名称：[春节活动-渠道A        ]      │
│  *礼包配置：[新手礼包 ▼              ]      │
│  *生成数量：[100000               ]      │
│                                          │
│  ▶ 高级选项（点击展开）                    │
│                                          │
│         [  提交生成  ]                    │
└─────────────────────────────────────────┘

点击"高级选项"后展开：
┌─────────────────────────────────────────┐
│  码格式：[自定义 ▼]                       │
│  格式模板：[XXXX-XXXX-XXXX          ]     │
│  有效期：[7天 ▼]                          │
│  分批策略：[自动分表 ▼]                    │
│  优先级：[普通 ▼]                          │
└─────────────────────────────────────────┘

┌─────────────────────────────────────────┐
│  任务进度：春节活动-渠道A                  │
├─────────────────────────────────────────┤
│  ████████████████░░░░  80%              │
│                                          │
│  已生成：80,000 / 100,000                 │
│  预计剩余：30秒                           │
│  当前阶段：批量入库                        │
│                                          │
│  [  暂停  ]  [  取消  ]                   │
└─────────────────────────────────────────┘

6.2 批次管理功能

筛选条件：
┌─────────────────────────────────────────┐
│  活动名称：[              ] 🔍          │
│  渠道：    [全部 ▼]                      │
│  状态：    [全部 ▼]                      │
│  时间范围：[2024-01-01] 至 [2024-12-31] │
│                          [  查询  ]      │
└─────────────────────────────────────────┘

结果列表：
┌────────────────────────────────────────────────────────────┐
│ 批次ID │ 名称          │ 数量    │ 使用率 │ 状态 │ 操作    │
├────────┼───────────────┼─────────┼────────┼──────┼─────────┤
│ 1001   │ 春节-华为     │ 100,000 │ 45%    │ 正常 │ [详情]  │
│ 1002   │ 春节-小米     │ 50,000  │ 32%    │ 正常 │ [详情]  │
│ 1003   │ 元宵-官网     │ 200,000 │ 0%     │ 待生效│ [作废] │
└────────────────────────────────────────────────────────────┘

导出： 导出未使用的码（CSV/Excel）
延期： 批量延长有效期
作废： 批量标记为无效
调整配置： 批量修改礼包内容（仅限未使用的码）

6.3 数据统计与可视化

┌─────────────────────────────────────────────────────────────┐
│                      礼包码数据看板                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  总生成量           总使用量           使用率               │
│  ┌─────────┐      ┌─────────┐      ┌─────────┐            │
│  │ 1250万  │      │  480万  │      │  38.4%  │            │
│  └─────────┘      └─────────┘      └─────────┘            │
│                                                             │
│  渠道使用率排行：                                            │
│  ┌──────────────────────────────────────────────────────┐  │
│  │ 1. 官网礼包    ████████████████████  78%            │  │
│  │ 2. 华为渠道    ████████████████░░░░  65%            │  │
│  │ 3. 小米渠道    ████████████░░░░░░░░  45%            │  │
│  │ 4. OPPO渠道    ████████░░░░░░░░░░░░  32%            │  │
│  │ 5. VIVO渠道    ██████░░░░░░░░░░░░░░  28%            │  │
│  └──────────────────────────────────────────────────────┘  │
│                                                             │
│  近7天使用趋势：                                             │
│  ┌──────────────────────────────────────────────────────┐  │
│  │         ╭──╮                                         │  │
│  │        ╭╯  ╰╮           ╭─╮                         │  │
│  │    ╭───╯    ╰───╮    ╭──╯ ╰──╮                      │  │
│  │ ───╯            ╰───╯        ╰──                    │  │
│  │  02/01 02/02 02/03 02/04 02/05 02/06 02/07         │  │
│  └──────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

七、错误处理与回滚机制

7.1 错误分类

可恢复错误： 数据库连接超时、网络抖动，重试可以解决
不可恢复错误： 配置错误、权限不足，需要人工修正
部分失败： 大部分成功，少量失败，需要记录原因并支持单独重试

7.2 重试机制

func retryWithBackoff(fn func() error, maxRetries int) error {
    backoff := 1 * time.Second
    
    for i := 0; i < maxRetries; i++ {
        err := fn()
        if err == nil {
            return nil
        }
        
        if i < maxRetries - 1 {
            time.Sleep(backoff)
            backoff *= 2  // 指数退避
            if backoff > 30*time.Second {
                backoff = 30 * time.Second  // 最大退避时间
            }
        }
    }
    
    return errors.New("max retries exceeded")
}

// 使用唯一键保证幂等
func insertCodeWithIdempotency(code *GiftCode) error {
    result, err := db.Exec(`
        INSERT INTO gift_codes (code, batch_id, ...) 
        VALUES (?, ?, ...)
        ON DUPLICATE KEY UPDATE code = code  -- 无实际更新，仅保证幂等
    `, code.Code, code.BatchID)
    
    if err != nil {
        return err
    }
    
    affected, _ := result.RowsAffected()
    if affected == 0 {
        return ErrCodeAlreadyExists
    }
    
    return nil
}

7.3 回滚机制

-- 软删除批次
UPDATE gift_code_batches SET status = 4 WHERE batch_id = ?;
UPDATE gift_codes SET status = 2 WHERE batch_id = ?;

-- 硬删除（谨慎使用，通常不推荐）
-- DELETE FROM gift_codes WHERE batch_id = ?;

7.4 断点续传

记录生成进度，重启后从断点继续，而非从头开始。关键：状态持久化，不能只存在内存中。

type TaskProgress struct {
    TaskID       string
    CurrentIndex int
    TotalCount   int
    Status       string  // running/paused/completed/failed
    UpdatedAt    time.Time
}

// 保存进度（持久化到 Redis 或数据库）
func saveProgress(progress *TaskProgress) error {
    return redis.Set(
        fmt.Sprintf("task:progress:%s", progress.TaskID),
        progress,
        24*time.Hour,
    )
}

// 恢复任务
func resumeTask(taskID string) error {
    progress := loadProgress(taskID)
    if progress == nil {
        return errors.New("task not found")
    }
    
    // 从断点继续
    for i := progress.CurrentIndex; i < progress.TotalCount; i++ {
        generateCode(i)
        
        // 定期保存进度
        if i % 1000 == 0 {
            saveProgress(&TaskProgress{
                TaskID:       taskID,
                CurrentIndex: i,
                TotalCount:   progress.TotalCount,
            })
        }
    }
    
    return nil
}

八、常见问题与解决方案

Q1：生成速度太慢，达不到业务要求？

确认瓶颈在哪里（CPU/内存/数据库/网络）
数据库写入通常是最大瓶颈
检查是否有不必要的索引（写入时索引维护开销大）

使用批量插入代替单条插入
临时禁用非关键索引，生成完再重建
分表并行写入
使用消息队列异步写入

Q2：生成过程中服务器宕机，怎么恢复？

启动时检查未完成的任务（状态为"进行中"）
读取最后保存的进度点
从断点继续生成
如果无法确定断点，可以选择：

- 作废当前批次，重新生成

- 从数据库查询已生成的最大序号，继续生成

Q3：如何防止运营误操作（如填错数量）？

前端校验： 数量输入框限制最大值，超出范围禁止提交
后端校验： 再次校验请求合法性
审批流程： 大批量（如超过 10 万）需要二次确认或审批
权限控制： 根据角色限制最大可生成数量

// 校验逻辑示例
func validateRequest(req *BatchRequest) error {
    // 数量范围校验
    if req.TotalCount <= 0 || req.TotalCount > 10000000 {
        return errors.New("数量必须在 1-10000000 之间")
    }
    
    // 大批量需要审批
    if req.TotalCount > 100000 && !req.Approved {
        return errors.New("超过 10 万需要审批")
    }
    
    // 权限校验
    if req.TotalCount > user.MaxBatchSize {
        return errors.New("超出您的权限范围")
    }
    
    return nil
}

Q4：不同渠道的码能混用吗？

无法追踪渠道效果
无法精准控制发放范围
出问题时难以定位

Q5：生成大量码后，查询变慢怎么办？

按时间或批次分表
对常用查询字段建索引
使用预聚合表存储统计数据
热数据缓存到 Redis

九、总结

批量创建系统是运营的"核武器"，它的价值在于：

性能优化：预分配、并行化、批量化、异步化
一致性保障：事务控制、幂等设计、断点续传
可追溯性：批次标识、元数据记录、审计日志
容错能力：错误分类、重试机制、回滚策略

序号预分配：减少中央服务压力，各节点并行工作
分片并行：大任务拆小任务，分而治之
批量存储：从逐条到批量到 Load Data，性能提升 100 倍
流式处理：避免内存溢出，边生成边存储
渐进式界面：让复杂技术对用户透明

批量创建系统不只是"多生成几个码"，而是一套完整的工程体系。技术是手段，业务价值才是目的。好的系统，应该让复杂的技术对使用者透明，只留下简单高效的体验。

*本文是游戏运营系统技术分享系列第三篇，

返回文章列表返回首页

💬 评论 (0)

0/500

排序：