在高并发场景中生成唯一且顺序递增的订单号时，如果频繁与数据库或 Redis 交互，性能可能会成为瓶颈。为了解决这个问题，我们可以设计一种从 Redis 预获取顺序号段并在本地缓存中生成订单号的方案。这种方法可以减少 Redis 访问频率，同时保持订单号的唯一性和顺序性。

本文将详细介绍如何实现该方案，包括设计原理、实现步骤、优化策略及注意事项。

1. 需求分析

订单号的生成规则如下：

• 格式：yyyyMMdd + 顺序号，如 20241016 001 表示2024年10月16日生成的第1个订单。
• 顺序号：每天的顺序号从 1 开始递增，并按订单生成的顺序依次递增。
• 在高并发情况下，要求订单号生成具有高性能和顺序性，且顺序号不能重复。

为提升性能，我们引入本地缓存的概念：

• Redis 存储： Redis 维护一个全局的顺序号计数器，每次从 Redis 获取一定范围的顺序号（如1-100）。
• 本地缓存： 启动时预先从 Redis 获取一个顺序号段，并在本地缓存中生成订单号。当本地缓存用尽时，再从 Redis 获取一个新的顺序号段。

2. 方案设计

2.1 设计思路

• Redis 作为全局顺序号生成器： 每次从 Redis 获取一段连续的顺序号（如1-100），并将其存储在本地缓存中。
• 本地缓存顺序号： 服务器从 Redis 获取顺序号段后，缓存在本地。在本地缓存的顺序号段用尽之前，所有的订单ID生成只需在本地完成，无需频繁访问 Redis。
• 顺序号段更新： 当本地缓存即将耗尽时，重新从 Redis 获取下一个顺序号段，确保顺序号的连续性。

2.2 Redis 数据结构

我们可以使用 Redis 的 INCRBY 命令来递增顺序号。每次服务器向 Redis 请求时，可以一次性递增指定数量的顺序号并将结果返回。

• 键名：使用当前日期作为键名，如 order:20241016，以便每天的顺序号从 1 开始。
• 值：当前顺序号，通过 INCRBY 实现。

2.3 本地缓存策略

• 初始顺序号段： 启动时，从 Redis 获取一个顺序号段并缓存在本地。假设初始获取的顺序号段是 1-100。
• 使用顺序号段： 每次生成订单号时，使用本地缓存中的顺序号，生成订单ID为 yyyyMMdd + 顺序号。
• 顺序号段耗尽： 当顺序号段即将用尽时（如剩余不足10个号），从 Redis 获取新的顺序号段（如 101-200），并继续在本地生成订单号。

2.4 顺序号生成流程图

1. 初始化：

启动时从 Redis 获取当天的顺序号段（如 1-100）。

将顺序号段缓存在本地内存中，供后续订单生成使用。

2. 订单生成：

当有新的订单请求时，从本地缓存中获取顺序号，并拼接当前日期，生成订单号。

如果本地缓存即将用尽（如剩余不足 10 个顺序号），向 Redis 请求新的顺序号段。

3. 顺序号段更新：

从 Redis 获取新的一段顺序号（如 101-200），更新本地缓存。

3. 实现步骤

3.1 Redis 配置

在 Redis 中，我们通过 INCRBY 操作来实现全局顺序号的递增。

# Redis 命令示例
INCRBY order:20241016 100

该命令将 order:20241016 的值增加 100，并返回新的值。

3.2 代码实现

我们可以使用 Java 和 Spring Boot 来实现该方案，具体代码如下：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;

import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

@Service
public class OrderIdService {

    @Autowired
    private StringRedisTemplate redisTemplate;

    private static final int THRESHOLD = 10; // 缓存即将用尽的临界值
    private int currentOrderNumber = 0;
    private int maxOrderNumber = 0;
    private Lock lock = new ReentrantLock();

    /**
     * 获取订单ID
     */
    public String getOrderId() {
        lock.lock();
        try {
            // 如果缓存中的顺序号即将用尽，重新从 Redis 获取新的顺序号段
            if (currentOrderNumber >= maxOrderNumber - THRESHOLD) {
                fetchOrderNumbersFromRedis();
            }

            // 生成订单ID
            String date = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyyMMdd"));
            return date + String.format("%03d", currentOrderNumber++);
        } finally {
            lock.unlock();
        }
    }

    /**
     * 从 Redis 获取顺序号段
     */
    private void fetchOrderNumbersFromRedis() {
        String date = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyyMMdd"));
        String key = "order:" + date;

        // 每次从 Redis 获取100个顺序号
        Long nextOrderNumber = redisTemplate.opsForValue().increment(key, 100);
        if (nextOrderNumber != null) {
            currentOrderNumber = nextOrderNumber.intValue() - 99; // 下一个顺序号的起始值
            maxOrderNumber = nextOrderNumber.intValue(); // 顺序号段的最大值
        }
    }
}

3.3 使用示例

@Autowired
private OrderIdService orderIdService;

public void createOrder() {
    String orderId = orderIdService.getOrderId();
    System.out.println("生成的订单ID: " + orderId);
    // 继续处理订单的其他逻辑
}

3.4 Redis 键失效处理

为防止 Redis 中存储的键无限增长，可以为每天的顺序号设置过期时间。通过 EXPIRE 命令，可以将键的生命周期设置为 24 小时。

EXPIRE order:20241016 86400

4. 优化策略

4.1 顺序号段预加载

为了避免在高并发场景下频繁访问 Redis，可以设置更高的缓存预加载阈值。例如，每次从 Redis 获取更大的顺序号段（如 500-600）以减少 Redis 的交互次数。

4.2 异步刷新顺序号段

当本地缓存即将耗尽时，可以通过异步线程预先向 Redis 请求新的一段顺序号，避免在订单生成的关键路径中等待 Redis 响应。

4.3 本地缓存多线程安全

在多线程环境下，为了保证顺序号的安全性，使用 ReentrantLock 对顺序号的读取和更新进行加锁，避免并发问题。

5. 注意事项

5.1 Redis 可用性

系统对 Redis 的依赖较大，因此需要确保 Redis 的高可用性。例如，可以配置 Redis 哨兵模式或集群模式，保障系统在 Redis 故障时能够快速恢复。

5.2 时间同步问题

如果服务器的时间不同步，可能会导致多个服务器生成不同日期的订单号，造成混乱。因此，确保所有服务器的时间同步非常重要，可以考虑使用 NTP 服务。

5.3 顺序号冲突

在高并发情况下，如果 Redis 存在短暂不可用的情况，可能会导致顺序号段无法及时刷新。为了防止这种情况，可以在业务逻辑中增加唯一性检查。

6. 总结

通过 Redis 预先获取顺序号段并在本地缓存顺序号生成订单ID，可以大幅提高系统在高并发下的性能表现。Redis 的 INCRBY 操作能够高效地生成全局唯一的顺序号，而本地缓存机制则减少了与 Redis 交互的频率，使得订单ID生成更加高效。